Date: Mon, 25 Jan 2021 22:56:21 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 252981] panic with ZFS encryption and QAT: VERIFY3(0 == spa_do_crypt_bad(... Message-ID: <bug-252981-3630-tnjs5tl2Kr@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-252981-3630@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252981 --- Comment #2 from Mark Johnston <markj@FreeBSD.org> --- (In reply to Mark Johnston from comment #1) With this fixed I hit the same panic as in the PR title. QAT has some weird constraints around the AAD length for GCM/CCM; in particular, it must be no more than 240 bytes in length. This is implemented in the Intel and DPDK QAT drivers as well as ours. ZFS is submitting GCM encryption requests with a large AAD (I think when encrypting a block of dnodes?) and hitting the check in qat_process(), and it can't tolerate the error. Weirdly, the ZFS QAT stub for Linux has no check for this case, but it also only uses QAT for data blocks, which I believe have no AAD. See qat_crypt_use_accel(). So for now we should at least change ZFS to not use hardware crypto since it doesn't work and clearly hasn't been tested (see comment 1). I'm not sure how hard it would be to permit the use of hardware crypto only for data blocks (and not for the ZIL and dnode blocks, which requires support for large AAD buffers. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252981-3630-tnjs5tl2Kr>