Page MenuHomeFreeBSD

Relnotes/13.0: changed AES-NI identification by geli
ClosedPublic

Authored by freebsd_michael-bueker.de on Mar 15 2021, 11:25 PM.

Details

Summary

A user on IRC wondered why his AES-NI-enabled CPU was identified by geli as "Crypto: accelerated software" on a 13.0-RC, when 12.2 identified it as "Crypto: hardware". From the ensuing discussion, I learned that this is a trivial identification change, and doesn't mean reduced encryption acceleration support. As I would have run into the same confusion, I think it's worth including in the Release Notes.

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Can you find a commit hash for this changed behaviour?

It would be ideal to attach it at the end.

more context, added info to corresponding paragraph

It seems to me that geli(4) doesn't exist, whereas geli(8) does, so this is changed throughout the Release Notes.

debdrup added a subscriber: jhb.

Looks good to me.

I think @jhb should weigh in too, just in case.

Once accepted, I'll commit it.

This revision is now accepted and ready to land.Mar 20 2021, 10:14 AM

I would do the geli(4) -> geli(8) as a separate commit FWIW.

website/content/en/releases/13.0R/relnotes.adoc
228

The new comment is related to this commit, not with adding aesni(4) to GENERIC. However, I would probably instead add an entirely new entry referencing commit a3d565a1188f, something like:

man:geli[8] now reports the use of accelerated software cryptography
(such as AES-NI on x86 CPUs) as "accelerated software" rather than "hardware".
gitref:a3d565a1188f[repository=src] {{< sponsored "Chelsio Communications" >}}

I agree, with just one further suggestion. Feel free to commit, and thanks for your time!

website/content/en/releases/13.0R/relnotes.adoc
228

I'd suggest explicitly mentioning that this doesn't imply reduced support. Both on the Forums and on IRC, users have asked whether cryptography will be slower for them with the new identification. I understand it's implied in this minimal phrasing that it won't be, but a little more verbosity couldn't hurt to avoid further questions.

website/content/en/releases/13.0R/relnotes.adoc
228

Agreed, bringing in your last sentence from below would suit that.