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/> References: <bug-252981-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252981 --- 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 Q= AT 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 buff= ers. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-252981-3630-tnjs5tl2Kr>