stable/13, aesni and geli

Something I have noticed while trying out 13.0-STABLE:

aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
is loaded as usual with my E3-1245v5 CPU, however, to my surprise geli shows now running on software:

GEOM_ELI: Device da1s1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI: Crypto: accelerated software
So I did ponder on one of my lacy maintained -CURRENT, and turns out that r359373 is the last kernel version whereas geli reports crypto as "Hardware". Reading thru the change logs it appears larger change got applied to AESNI and kernel crypto framework. I am wondering now, if aesni is still supported with geli or thats only cosmetic?

Yze
 
Yes, to me it also shows Crypto: accelerated software on 13.0-BETA3
But so far it just looks like they are doing some changes, so I would first wait for 13.0-RELEASE.
 
As our tradition is to test new major release on our poor "lab" box that does run a lot of test jails, we have now upgraded that box to 13-STABLE and went ahead replacing GELI with zfs native encryption. That mirror performs already much better as we could also leave some datasets unencrypted were no confidentially is needed.
But still, would be sad to see if GELI becomes deprecated, without AESNI storage encryption for any of our servers would make no sense today anymore. And some server might want to use GELI+UFS2 still.
 
I do not think that GELI becomes deprecated, I would raise an objection against that. One still needs GELI for encrypting swap and like you said also for ppl who are still using UFS2, like me on cloud droplets and on machines with little RAM.
AESNI is also not away, it is just not built as kernel module any more, it says to me that it is already part of the kernel.
So they made it built in like OpenBSD does.
 
So I did ponder on one of my lacy maintained -CURRENT, and turns out that r359373 is the last kernel version whereas geli reports crypto as "Hardware". Reading thru the change logs it appears larger change got applied to AESNI and kernel crypto framework. I am wondering now, if aesni is still supported with geli or thats only cosmetic?
This was also discussed on IRC recently, and devs have confirmed that it's purely cosmetic.

There's a review running for a change to the release notes of 13.0, and it will probably be mentioned there, which hopefully avoids confusion.
 
There's a review running for a change to the release notes of 13.0, and it will probably be mentioned there, which hopefully avoids confusion.
It's landed in the 13.0 Release Notes:
geli(8) now reports the use of accelerated software cryptography (such as AES-NI on x86 CPUs) as "accelerated software" rather than "hardware". This is purely a change in naming, and does not imply reduced performance or support. a3d565a1188f (Sponsored by Chelsio Communications)
 
As our tradition is to test new major release on our poor "lab" box that does run a lot of test jails, we have now upgraded that box to 13-STABLE and went ahead replacing GELI with zfs native encryption. That mirror performs already much better as we could also leave some datasets unencrypted were no confidentially is needed.
But still, would be sad to see if GELI becomes deprecated, without AESNI storage encryption for any of our servers would make no sense today anymore. And some server might want to use GELI+UFS2 still.

I hope you do understand that ZFS native encryption does not encrypt everything. Many metadata stay unencrypted and as such expose information to some external analysis. Even dataset names and snapshot names stay unencrypted. I would stay with geli.

I honestly don't know why they don't offer native encryption on VDEV level. That would have been much more elegant.
 
A quick-start guide to OpenZFS native encryption | Ars Technica (2021-06-23)

Some of the background can be found in:


 
Back
Top