# stable/13, aesni and geli



## Yze (Feb 12, 2021)

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


----------



## gustopn (Feb 20, 2021)

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.


----------



## Yze (Feb 20, 2021)

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.


----------



## gustopn (Feb 20, 2021)

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.


----------



## SirDice (Feb 21, 2021)

geli(8) isn't going anywhere, it has plenty of other uses.


----------



## mtu (Mar 20, 2021)

Yze said:


> 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.


----------



## steps (Mar 20, 2021)

SirDice said:


> geli(8) isn't going anywhere, it has plenty of other uses.



It is still needed for an encrypted root, see Thread loader.efi cannot boot native encrypted ZFS root.79381


----------



## mtu (Mar 23, 2021)

mtu said:


> 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)_


----------



## Dragony (Sep 24, 2021)

Yze said:


> 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.


----------



## grahamperrin@ (Sep 26, 2021)

A quick-start guide to OpenZFS native encryption | Ars Technica (2021-06-23)

Some of the background can be found in: 









						ZFS Encryption by tcaputi · Pull Request #4329 · openzfs/zfs
					

Native encryption in zfsonlinux (See issue #494) The change incorporates 2 major pieces: The first feature is a keystore that manages wrapping and encryption keys for encrypted datasets. The comman...




					github.com
				












						ZFS Encryption by tcaputi · Pull Request #5769 · openzfs/zfs
					

Native encryption in zfsonlinux (See issue #494) The change incorporates 2 major pieces: The first feature is a keystore that manages wrapping and encryption keys for encrypted datasets. The comman...




					github.com


----------

