FreeBSD: disable the use of hardware crypto offload drivers for now #11612
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
approved these changes
Feb 17, 2021
ghost
added
Component: Encryption
|
IIRC, software AES-CCM crypto on FreeBSD is single-threaded and extremely slow. |
|
Ah, nevermind probably, on 13 we have aesni(4) reporting as CRYPTOCAP_F_SOFTWARE | CRYPTOCAP_F_ACCEL_SOFTWARE, so it should be acceptable. |
Right, it is not my intention to disable use of aesni(4). But you are right, on 12 aesni(4) reports as a hardware driver... |
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. The plan is to implement such a fallback mechanism, but with FreeBSD 13.0 approaching we should simply disable the use hardware drivers for now. Signed-off-by: Mark Johnston <[email protected]>
|
Updated to limit the change to FreeBSD 13 and later, and to a comment explaining the difference. |
|
I see the new comment, but not version checks. What am I missing? |
|
There are two implementations of |
|
Ah. OK. :) |
behlendorf
added
Status: Accepted
|
@behlendorf I have no idea about the original problem, but the workaround is OK for me. |
amotin
approved these changes
Feb 18, 2021
behlendorf
pushed a commit
that referenced
this pull request
Mar 5, 2021
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. The plan is to implement such a fallback mechanism, but with FreeBSD 13.0 approaching we should simply disable the use hardware drivers for now. Reviewed-by: Ryan Moeller <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Mark Johnston <[email protected]> Closes #11612
jsai20
pushed a commit
to jsai20/zfs
that referenced
this pull request
Mar 30, 2021
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. The plan is to implement such a fallback mechanism, but with FreeBSD 13.0 approaching we should simply disable the use hardware drivers for now. Reviewed-by: Ryan Moeller <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Mark Johnston <[email protected]> Closes openzfs#11612
sempervictus
pushed a commit
to sempervictus/zfs
that referenced
this pull request
May 31, 2021
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. The plan is to implement such a fallback mechanism, but with FreeBSD 13.0 approaching we should simply disable the use hardware drivers for now. Reviewed-by: Ryan Moeller <[email protected]> Reviewed-by: Alexander Motin <[email protected]> Signed-off-by: Mark Johnston <[email protected]> Closes openzfs#11612
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Disable the use of hardware crypto offloads when using ZFS' encryption capabilities on FreeBSD.
Motivation and Context
A couple of problems, detailed in the commit message, prevent ZFS encryption from working properly with hardware offload drivers on FreeBSD. As a temporary measure, prevent ZFS from using such drivers.
Description
The change modifies FreeBSD-specific crypto session setup code such that only software drivers (e.g., AES-NI wrappers) will be used. I believe this will not present a regression for any users since a bug in the FreeBSD crypto request completion handler means that asynchronous completions are not handled correctly.
How Has This Been Tested?
Build-tested, made the corresponding modification to FreeBSD's in-tree copy of ZFS and verified that it refuses to attach to hardware drivers.
Types of changes
Checklist:
Signed-off-by.