Enable accelerated AES-XTS software crypto in GENERIC.

[jhb]

Summary

In particular, using GELI on a root filesystem will only use
accelerated software crypto drivers if they are available before the
root filesystem is mounted. While these modules can be loaded from
the loader, including them in GENERIC provides a better out-of-the-box
experience for users.

Both aesni(4) and armv8crypto(4) provide accelerated implementations
of the default cipher used by GELI (AES-XTS) in addition to other
ciphers.

[emaste]

LGTM

[mhorne]

Would there be any benefit (or risk) to enabling ossl(4) by default as well?

sys/amd64/conf/GENERIC

129

You might add a section heading, as in D28099, but there are plenty of entries that don't.

[jhb]

sys/amd64/conf/GENERIC

129

You might add a section heading, as in D28099, but there are plenty of entries that don't.

In this case it didn't seem quite worth it for this single line. OTOH, perhaps this should be next to 'device crypto'? The "pseudo devices" section is really poorly named, but I probably should move them next to 'crypto' at least.

[jhb]

I don't yet think ossl(4) is perhaps worth it. Just doing faster SHA is kind of a narrow case (you have to go out of your way to ask for it for GELI for example). If we expand ossl(4) to support AES algorithms and it is competitive (or outperforms) aesni(4) and/or armv8crypto(4), then I think we can revisit what to do about ossl(4).

[jhb]

• Move device lines into more relevant places.

[jhb]

sys/amd64/conf/GENERIC

320

Ideally we wouldn't be mixing and matching random network things in with crypto, PRNG, etc. At least we could group all the network ones together which would be nice as a separate group from the non-network ones. The hardware RNGs should be nicer if we still had 'device random' but I think that is in DEFAULTS instead of in GENERIC.

sys/arm64/conf/GENERIC

222

I put this here instead of next to 'device crypto' for arm64. Arguably, 'device crypto' should be in this section.

[markj]

Am I right that at present we have no way to disable the use of a particular crypto driver? If, say, a bug in a driver is causing problems or I want to compare perf between sw and hw drivers, I have no recourse but to recompile the kernel?

[jhb]

Well, there are some gross ways. /dev/crypto consumers can request a specific driver by crid as can individual kernel consumers though I don't think any other in-kernel consumers provide a way to allow users to control the crid used to create sessions. Since opencrypto_if.m requires device_t objects, all drivers have device instances that can be detached or disabled via devctl(8). That's a bit of a weird way to do it, but 'devctl disable aesni0' would probably be the closest thing we have. On the other hand, that would only work if the device was idle (no active sessions). We don't have a way to forcefully remove a device and have sessions gracefully fail over to another driver. There's some notion of session failover in OCF, but only IPsec honors it, and it's kind of gross. What I'd rather do is make "user-facing" sessions a kind of mux where you can give a policy at session creation time of "exactly this crid, or use these class of drivers", perhaps via the existing crid option when creating a session and then allow a crypto "consumer session" to bind to 1 or more "driver sessions", and even allow a driver session to be detached, so e.g. "devctl detach -f aesni0" would work, or also things like a crypto accelerate going away due to a forceful detach (e.g. hotplug detach). You might also imagine performance-guided policies where small buffers use accelerated software and larger buffers use a co-processor that such an abstraction might permit. That would be a good pile of work to achieve though I think.

[markj]

In D28100#628210, @jhb wrote:

Well, there are some gross ways. /dev/crypto consumers can request a specific driver by crid as can individual kernel consumers though I don't think any other in-kernel consumers provide a way to allow users to control the crid used to create sessions. Since opencrypto_if.m requires device_t objects, all drivers have device instances that can be detached or disabled via devctl(8). That's a bit of a weird way to do it, but 'devctl disable aesni0' would probably be the closest thing we have. On the other hand, that would only work if the device was idle (no active sessions). We don't have a way to forcefully remove a device and have sessions gracefully fail over to another driver. There's some notion of session failover in OCF, but only IPsec honors it, and it's kind of gross. What I'd rather do is make "user-facing" sessions a kind of mux where you can give a policy at session creation time of "exactly this crid, or use these class of drivers", perhaps via the existing crid option when creating a session and then allow a crypto "consumer session" to bind to 1 or more "driver sessions", and even allow a driver session to be detached, so e.g. "devctl detach -f aesni0" would work, or also things like a crypto accelerate going away due to a forceful detach (e.g. hotplug detach). You might also imagine performance-guided policies where small buffers use accelerated software and larger buffers use a co-processor that such an abstraction might permit. That would be a good pile of work to achieve though I think.

I didn't realize that one can use devctl with crypto devices. I think that's probably sufficient for the case that I'm worried about, where one has an embedded device and wants to disable some crypto driver to work around a problem.

[allanjude]

Looks good to me. This will also accelerate AES-GCM by default on ARMv8 once D27454 lands

Also if Drew enables KTLS by default as well, then this all fits together very nicely.