diff options
| author | Martin Matuska <mm@FreeBSD.org> | 2021-02-22 17:37:47 +0000 |
|---|---|---|
| committer | Martin Matuska <mm@FreeBSD.org> | 2021-02-22 17:42:33 +0000 |
| commit | 940415f20a784156ec0e247989796385896f32a8 (patch) | |
| tree | eea82a2f83515cb54d17efe4dea8330f82592904 | |
| parent | 64649f0285424435634c2dfd39f49536fc2b50dd (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.c | 15 |
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++; |
