Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On Fri, Mar 27, 2020 at 1:31 PM John Baldwin wrote: > > Author: jhb > Date: Fri Mar 27 18:25:23 2020 > New Revision: 359374 > URL: https://svnweb.freebsd.org/changeset/base/359374 > > Log: > Refactor driver and consumer interfaces for OCF (in-kernel crypto). > > [... snip ...] Hi John, ^/sys/modules/crypto needs opt_compat.h added to SRCS after this commit. :-) Thanks, Kyle Evans ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On 4/13/20 12:31 PM, Warner Losh wrote: > On Mon, Apr 13, 2020 at 1:22 PM John-Mark Gurney wrote: > >> John Baldwin wrote this message on Mon, Apr 13, 2020 at 09:56 -0700: >>> On 4/12/20 1:08 PM, Xin Li wrote: On 3/27/20 11:25 AM, John Baldwin wrote: [...]> - Drivers no longer register a list of supported algorithms. >> This > doesn't quite work when you factor in modes (e.g. a driver might > support both AES-CBC and SHA2-256-HMAC separately but not combined > for ETA). Instead, a new 'crypto_probesession' method has been > added to the kobj interface for symmteric crypto drivers. This > method returns a negative value on success (similar to how > device_probe works) and the crypto framework uses this value to >> pick > the "best" driver. There are three constants for hardware > (e.g. ccr), accelerated software (e.g. aesni), and plain software > (cryptosoft) that give preference in that order. One effect of >> this > is that if you request only hardware when creating a new session, > you will no longer get a session using accelerated software. > Another effect is that the default setting to disallow software > crypto via /dev/crypto now disables accelerated software. For user-visible interface, it seems like we are essentially treating "accelerated software" like AES-NI the same way of plain software. For example, geom_eli would now say: GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software Instead of: GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware When AES-NI is used (which is because we only have two bits to >> represent hardware and software, and have gave neither bits clear with its own meaning (use specific driver)). If we are not going to add a new bit to represent accelerated software, why are they categorized as software providers? Technically, all these still requires hardware that implements the cryptographic primitives to work, and it's much easier for system administrators if we expose the fact that they are using some kind of acceleration than asking them to run DTrace etc. to find out. Personally, I think it's probably better to change the notion to either "accelerated" (by either hardware or software) and "software"... >>> >>> The only case where this is visible is in fact GELI (there is no printf >>> for IPsec or KTLS). For /dev/crypto using aesni.ko is a bug, not a >>> feature, as any such software would be much better off using AES-NI in >>> userland instead of round-tripping through the kernel. We could add a >>> bit to appease the GELI printf, or we could just kill the GELI >>> printf. I think a more useful approach would probably be to kill the >>> GELI printf and instead add something less GELI-specific such as >>> counters of active sessions for the various cryptographic drivers that >>> would show which drivers are in use for any in-kernel crypto. This >>> approach also lends itself to supporting a more flexible API where a >>> single crypto session might be backed by multiple drivers where a >>> binary hardware / software setting might not even make sense as you >>> might have a mix. (I know of other out-of-tree crypto use cases that >>> experimented with splitting in-kernel crypto workloads between an >>> async co-processor and AES-NI.) >> >> As long as there remains some what to warn the user that when they've >> mounted a geli volume that they're using slow crypto, I'm fine... >> >> We have done a bad job on doing the right thing, and I'm afraid that >> removing this print w/o doing something to address it will go from >> FreeBSD already not doing the right thing, but to not allowing the user >> to know that FreeBSD isn't doing the right thing. >> >> Even a simple print in the crypto driver when the processor supports >> AES-NI, but the aesni module isn't loaded would be useful.. >> >> Without the geli print, it's likely articles, like the recent Anandtech, >> will think FreeBSD's encrypted volumes are slow when it's just a failure >> for us to do the correct thing. >> >> I haven't looeked at the new code, but the resaon that aesni.ko was >> considered a hardware vs software device was that the existing crypto >> framework didn't have a well to tell the two apart, and it wasn't >> possible to select the aesni.ko routines over the software routines >> in a reliable manner. >> > > Seems to me this isn't a binary, but a triary: software, CPU assist, > hardware offload. but that maybe over-complicating things... The new code does the trinary under the hood for the interface between sessions and drivers. It's even documented that way now in crypto_driver.9: When a new session is created by crypto_newsession(), CRYPTODEV_PROBESESSION() is invoked by the cryptographic framework on
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On Mon, Apr 13, 2020 at 1:22 PM John-Mark Gurney wrote: > John Baldwin wrote this message on Mon, Apr 13, 2020 at 09:56 -0700: > > On 4/12/20 1:08 PM, Xin Li wrote: > > > > > > > > > On 3/27/20 11:25 AM, John Baldwin wrote: > > > [...]> - Drivers no longer register a list of supported algorithms. > This > > >> doesn't quite work when you factor in modes (e.g. a driver might > > >> support both AES-CBC and SHA2-256-HMAC separately but not combined > > >> for ETA). Instead, a new 'crypto_probesession' method has been > > >> added to the kobj interface for symmteric crypto drivers. This > > >> method returns a negative value on success (similar to how > > >> device_probe works) and the crypto framework uses this value to > pick > > >> the "best" driver. There are three constants for hardware > > >> (e.g. ccr), accelerated software (e.g. aesni), and plain software > > >> (cryptosoft) that give preference in that order. One effect of > this > > >> is that if you request only hardware when creating a new session, > > >> you will no longer get a session using accelerated software. > > >> Another effect is that the default setting to disallow software > > >> crypto via /dev/crypto now disables accelerated software. > > > > > > For user-visible interface, it seems like we are essentially treating > > > "accelerated software" like AES-NI the same way of plain software. For > > > example, geom_eli would now say: > > > > > > GEOM_ELI: Encryption: AES-XTS 128 > > > GEOM_ELI: Crypto: software > > > > > > Instead of: > > > > > > GEOM_ELI: Encryption: AES-XTS 128 > > > GEOM_ELI: Crypto: hardware > > > > > > When AES-NI is used (which is because we only have two bits to > represent > > > hardware and software, and have gave neither bits clear with its own > > > meaning (use specific driver)). > > > > > > If we are not going to add a new bit to represent accelerated software, > > > why are they categorized as software providers? Technically, all these > > > still requires hardware that implements the cryptographic primitives to > > > work, and it's much easier for system administrators if we expose the > > > fact that they are using some kind of acceleration than asking them to > > > run DTrace etc. to find out. Personally, I think it's probably better > > > to change the notion to either "accelerated" (by either hardware or > > > software) and "software"... > > > > The only case where this is visible is in fact GELI (there is no printf > > for IPsec or KTLS). For /dev/crypto using aesni.ko is a bug, not a > > feature, as any such software would be much better off using AES-NI in > > userland instead of round-tripping through the kernel. We could add a > > bit to appease the GELI printf, or we could just kill the GELI > > printf. I think a more useful approach would probably be to kill the > > GELI printf and instead add something less GELI-specific such as > > counters of active sessions for the various cryptographic drivers that > > would show which drivers are in use for any in-kernel crypto. This > > approach also lends itself to supporting a more flexible API where a > > single crypto session might be backed by multiple drivers where a > > binary hardware / software setting might not even make sense as you > > might have a mix. (I know of other out-of-tree crypto use cases that > > experimented with splitting in-kernel crypto workloads between an > > async co-processor and AES-NI.) > > As long as there remains some what to warn the user that when they've > mounted a geli volume that they're using slow crypto, I'm fine... > > We have done a bad job on doing the right thing, and I'm afraid that > removing this print w/o doing something to address it will go from > FreeBSD already not doing the right thing, but to not allowing the user > to know that FreeBSD isn't doing the right thing. > > Even a simple print in the crypto driver when the processor supports > AES-NI, but the aesni module isn't loaded would be useful.. > > Without the geli print, it's likely articles, like the recent Anandtech, > will think FreeBSD's encrypted volumes are slow when it's just a failure > for us to do the correct thing. > > I haven't looeked at the new code, but the resaon that aesni.ko was > considered a hardware vs software device was that the existing crypto > framework didn't have a well to tell the two apart, and it wasn't > possible to select the aesni.ko routines over the software routines > in a reliable manner. > Seems to me this isn't a binary, but a triary: software, CPU assist, hardware offload. but that maybe over-complicating things... Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
John Baldwin wrote this message on Mon, Apr 13, 2020 at 09:56 -0700: > On 4/12/20 1:08 PM, Xin Li wrote: > > > > > > On 3/27/20 11:25 AM, John Baldwin wrote: > > [...]> - Drivers no longer register a list of supported algorithms. This > >> doesn't quite work when you factor in modes (e.g. a driver might > >> support both AES-CBC and SHA2-256-HMAC separately but not combined > >> for ETA). Instead, a new 'crypto_probesession' method has been > >> added to the kobj interface for symmteric crypto drivers. This > >> method returns a negative value on success (similar to how > >> device_probe works) and the crypto framework uses this value to pick > >> the "best" driver. There are three constants for hardware > >> (e.g. ccr), accelerated software (e.g. aesni), and plain software > >> (cryptosoft) that give preference in that order. One effect of this > >> is that if you request only hardware when creating a new session, > >> you will no longer get a session using accelerated software. > >> Another effect is that the default setting to disallow software > >> crypto via /dev/crypto now disables accelerated software. > > > > For user-visible interface, it seems like we are essentially treating > > "accelerated software" like AES-NI the same way of plain software. For > > example, geom_eli would now say: > > > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: software > > > > Instead of: > > > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: hardware > > > > When AES-NI is used (which is because we only have two bits to represent > > hardware and software, and have gave neither bits clear with its own > > meaning (use specific driver)). > > > > If we are not going to add a new bit to represent accelerated software, > > why are they categorized as software providers? Technically, all these > > still requires hardware that implements the cryptographic primitives to > > work, and it's much easier for system administrators if we expose the > > fact that they are using some kind of acceleration than asking them to > > run DTrace etc. to find out. Personally, I think it's probably better > > to change the notion to either "accelerated" (by either hardware or > > software) and "software"... > > The only case where this is visible is in fact GELI (there is no printf > for IPsec or KTLS). For /dev/crypto using aesni.ko is a bug, not a > feature, as any such software would be much better off using AES-NI in > userland instead of round-tripping through the kernel. We could add a > bit to appease the GELI printf, or we could just kill the GELI > printf. I think a more useful approach would probably be to kill the > GELI printf and instead add something less GELI-specific such as > counters of active sessions for the various cryptographic drivers that > would show which drivers are in use for any in-kernel crypto. This > approach also lends itself to supporting a more flexible API where a > single crypto session might be backed by multiple drivers where a > binary hardware / software setting might not even make sense as you > might have a mix. (I know of other out-of-tree crypto use cases that > experimented with splitting in-kernel crypto workloads between an > async co-processor and AES-NI.) As long as there remains some what to warn the user that when they've mounted a geli volume that they're using slow crypto, I'm fine... We have done a bad job on doing the right thing, and I'm afraid that removing this print w/o doing something to address it will go from FreeBSD already not doing the right thing, but to not allowing the user to know that FreeBSD isn't doing the right thing. Even a simple print in the crypto driver when the processor supports AES-NI, but the aesni module isn't loaded would be useful.. Without the geli print, it's likely articles, like the recent Anandtech, will think FreeBSD's encrypted volumes are slow when it's just a failure for us to do the correct thing. I haven't looeked at the new code, but the resaon that aesni.ko was considered a hardware vs software device was that the existing crypto framework didn't have a well to tell the two apart, and it wasn't possible to select the aesni.ko routines over the software routines in a reliable manner. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On 4/12/20 1:08 PM, Xin Li wrote: > > > On 3/27/20 11:25 AM, John Baldwin wrote: > [...]> - Drivers no longer register a list of supported algorithms. This >> doesn't quite work when you factor in modes (e.g. a driver might >> support both AES-CBC and SHA2-256-HMAC separately but not combined >> for ETA). Instead, a new 'crypto_probesession' method has been >> added to the kobj interface for symmteric crypto drivers. This >> method returns a negative value on success (similar to how >> device_probe works) and the crypto framework uses this value to pick >> the "best" driver. There are three constants for hardware >> (e.g. ccr), accelerated software (e.g. aesni), and plain software >> (cryptosoft) that give preference in that order. One effect of this >> is that if you request only hardware when creating a new session, >> you will no longer get a session using accelerated software. >> Another effect is that the default setting to disallow software >> crypto via /dev/crypto now disables accelerated software. > > For user-visible interface, it seems like we are essentially treating > "accelerated software" like AES-NI the same way of plain software. For > example, geom_eli would now say: > > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software > > Instead of: > > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > > When AES-NI is used (which is because we only have two bits to represent > hardware and software, and have gave neither bits clear with its own > meaning (use specific driver)). > > If we are not going to add a new bit to represent accelerated software, > why are they categorized as software providers? Technically, all these > still requires hardware that implements the cryptographic primitives to > work, and it's much easier for system administrators if we expose the > fact that they are using some kind of acceleration than asking them to > run DTrace etc. to find out. Personally, I think it's probably better > to change the notion to either "accelerated" (by either hardware or > software) and "software"... The only case where this is visible is in fact GELI (there is no printf for IPsec or KTLS). For /dev/crypto using aesni.ko is a bug, not a feature, as any such software would be much better off using AES-NI in userland instead of round-tripping through the kernel. We could add a bit to appease the GELI printf, or we could just kill the GELI printf. I think a more useful approach would probably be to kill the GELI printf and instead add something less GELI-specific such as counters of active sessions for the various cryptographic drivers that would show which drivers are in use for any in-kernel crypto. This approach also lends itself to supporting a more flexible API where a single crypto session might be backed by multiple drivers where a binary hardware / software setting might not even make sense as you might have a mix. (I know of other out-of-tree crypto use cases that experimented with splitting in-kernel crypto workloads between an async co-processor and AES-NI.) Also, while AES-NI instructions are faster than plain C, they are still very much software rather than an engine like QAT or ccr(4). They run synchronously using host CPU cycles rather than async on a separate co-processor. This means that if you tweak the various geli sysctls for batching vs non-batching, etc. you need to make the same choices for both accelerated software and "plain" software vs possibly different choices for an async co-processor. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
Alexey Dokuchaev wrote this message on Mon, Apr 13, 2020 at 04:32 +: > On Sun, Apr 12, 2020 at 01:08:49PM -0700, Xin Li via svn-src-all wrote: > > On 3/27/20 11:25 AM, John Baldwin wrote: > > > - Drivers no longer register a list of supported algorithms. [...] > > > > For user-visible interface, it seems like we are essentially treating > > "accelerated software" like AES-NI the same way of plain software. For > > example, geom_eli would now say: > > > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: software > > > > Instead of: > > > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: hardware > > > > [...] and it's much easier for system administrators if we expose the > > fact that they are using some kind of acceleration than asking them to > > run DTrace etc. to find out. Personally, I think it's probably better > > to change the notion to either "accelerated" (by either hardware or > > software) and "software"... > > +1 for "accelerated" vs. "software". For most users "accelerated" would > mean AES-NI (dedicated crypto cards are not as common), and since most > modern CPUs have those, not being able to easily distinguish between that > and "pure software" (unaccelerated) mode is rather frustrating. Yeah, w/o a differentiation, people can't tell if the aesni.ko module was loaded or not... I use this to make sure things will go fast.. If I see software, I know it'll be slow... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On Sun, Apr 12, 2020 at 01:08:49PM -0700, Xin Li via svn-src-all wrote: > On 3/27/20 11:25 AM, John Baldwin wrote: > > - Drivers no longer register a list of supported algorithms. [...] > > For user-visible interface, it seems like we are essentially treating > "accelerated software" like AES-NI the same way of plain software. For > example, geom_eli would now say: > > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software > > Instead of: > > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: hardware > > [...] and it's much easier for system administrators if we expose the > fact that they are using some kind of acceleration than asking them to > run DTrace etc. to find out. Personally, I think it's probably better > to change the notion to either "accelerated" (by either hardware or > software) and "software"... +1 for "accelerated" vs. "software". For most users "accelerated" would mean AES-NI (dedicated crypto cards are not as common), and since most modern CPUs have those, not being able to easily distinguish between that and "pure software" (unaccelerated) mode is rather frustrating. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On 3/27/20 11:25 AM, John Baldwin wrote: [...]> - Drivers no longer register a list of supported algorithms. This > doesn't quite work when you factor in modes (e.g. a driver might > support both AES-CBC and SHA2-256-HMAC separately but not combined > for ETA). Instead, a new 'crypto_probesession' method has been > added to the kobj interface for symmteric crypto drivers. This > method returns a negative value on success (similar to how > device_probe works) and the crypto framework uses this value to pick > the "best" driver. There are three constants for hardware > (e.g. ccr), accelerated software (e.g. aesni), and plain software > (cryptosoft) that give preference in that order. One effect of this > is that if you request only hardware when creating a new session, > you will no longer get a session using accelerated software. > Another effect is that the default setting to disallow software > crypto via /dev/crypto now disables accelerated software. For user-visible interface, it seems like we are essentially treating "accelerated software" like AES-NI the same way of plain software. For example, geom_eli would now say: GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software Instead of: GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: hardware When AES-NI is used (which is because we only have two bits to represent hardware and software, and have gave neither bits clear with its own meaning (use specific driver)). If we are not going to add a new bit to represent accelerated software, why are they categorized as software providers? Technically, all these still requires hardware that implements the cryptographic primitives to work, and it's much easier for system administrators if we expose the fact that they are using some kind of acceleration than asking them to run DTrace etc. to find out. Personally, I think it's probably better to change the notion to either "accelerated" (by either hardware or software) and "software"... Cheers, ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/c
On 3/27/20 11:25 AM, John Baldwin wrote: > Author: jhb > Date: Fri Mar 27 18:25:23 2020 > New Revision: 359374 > URL: https://svnweb.freebsd.org/changeset/base/359374 > > Log: > Refactor driver and consumer interfaces for OCF (in-kernel crypto). I have tested as much as I have accessible. Someone did test cesa(4) I believe and found it worked with cryptocheck but not IPsec. I found a bug in the hash handling related to IPsec that I fixed in cesa(4), but the original submitter didn't retest. kp@ has an out-of-tree driver that he said works with these changes as well. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
