aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Matuska <mm@FreeBSD.org>2021-02-22 17:37:47 +0000
committerMartin Matuska <mm@FreeBSD.org>2021-02-22 17:42:33 +0000
commit940415f20a784156ec0e247989796385896f32a8 (patch)
treeeea82a2f83515cb54d17efe4dea8330f82592904
parent64649f0285424435634c2dfd39f49536fc2b50dd (diff)
zfs: disable use of hardware crypto offload drivers
From openzfs-master e7adccf7f commit message: First, the crypto request completion handler contains a bug in that it fails to reset fs_done correctly after the request is completed. This is only a problem for asynchronous drivers. Second, some hardware drivers have input constraints which ZFS does not satisfy. For instance, ccp(4) apparently requires the AAD length for AES-GCM to be a multiple of the cipher block size, and with qat(4) the AES-GCM AAD length may not be longer than 240 bytes. FreeBSD's generic crypto framework doesn't have a mechanism to automatically fall back to a software implementation if a hardware driver cannot process a request, and ZFS does not tolerate such errors. Patch Author: Mark Johnston <markj@freebsd.org> Obtained from: openzfs/zfs@e7adccf7f537a4d07281a2b74b360154bae367bc PR: 252981, 253595 MFS after: 3 days (direct commit)
-rw-r--r--sys/contrib/openzfs/module/os/freebsd/zfs/crypto_os.c15
1 files changed, 13 insertions, 2 deletions
diff --git a/sys/contrib/openzfs/module/os/freebsd/zfs/crypto_os.c b/sys/contrib/openzfs/module/os/freebsd/zfs/crypto_os.c
index b86ffc59a21d..0a7241699842 100644
--- a/sys/contrib/openzfs/module/os/freebsd/zfs/crypto_os.c
+++ b/sys/contrib/openzfs/module/os/freebsd/zfs/crypto_os.c
@@ -293,8 +293,19 @@ freebsd_crypt_newsession(freebsd_crypt_session_t *sessp,
error = ENOTSUP;
goto bad;
}
- error = crypto_newsession(&sessp->fs_sid, &csp,
- CRYPTOCAP_F_HARDWARE | CRYPTOCAP_F_SOFTWARE);
+
+ /*
+ * Disable the use of hardware drivers on FreeBSD 13 and later since
+ * common crypto offload drivers impose constraints on AES-GCM AAD
+ * lengths that make them unusable for ZFS, and we currently do not have
+ * a mechanism to fall back to a software driver for requests not
+ * handled by a hardware driver.
+ *
+ * On 12 we continue to permit the use of hardware drivers since
+ * CPU-accelerated drivers such as aesni(4) register themselves as
+ * hardware drivers.
+ */
+ error = crypto_newsession(&sessp->fs_sid, &csp, CRYPTOCAP_F_SOFTWARE);
mtx_init(&sessp->fs_lock, "FreeBSD Cryptographic Session Lock",
NULL, MTX_DEF);
crypt_sessions++;