UFS GELI hash changes depending on if hardware or software crypto is used?

[`Orum]

I'm trying to set up a new system using EFI + GELI + UFS2 + encrypted root, with GELI configured to use AES-XTS 256 and HMAC/SHA256. After dding over areas of the disk (start/end, to set up initial HMACs) and then newfsing, I noticed that GELI was not using hardware crypto, but software. After some reading on the forums here, I found that to get hardware crypto to work one has to detach, kldload aesni, and then reattach. This 'worked' in the sense that GELI now shows it's using hardware crypto; however, upon reattaching I got numerous "Failed to authenticate _____ bytes of data at offset ____." messages printed to the console.

This seems quite odd to me, as I would think the hardware and software crypto should produce identical results, differing only in the speed they achieve them. To double check things, I detached the partition, ran kldunload aesni, and reattached with software crypto again. No messages this time, so the HMACs were still valid with software (as that was being used when the data was written), and invalid when I switched to hardware.

Any idea why this would happen? Can anyone else replicate this?

 

[T-Daemon]

When the aesni(4) kernel module is loaded, the console (/var/log/messages) prints the supported AESNI set of instructions the CPU is capable of, is AES-XTS amongs them?

According to geli(8), if hardware crypto is available, it will make use of it automatically, but when the instruction set (encryption algorithm) in which the disk was encryped the CPU does not support, that could explaine the authentification failing.

I tested on a memory disk. With/without aesni makes no difference in attaching the disk:

geli init -a HMAC/SHA256 -e AES-XTS -l 256 -s 4096 -K key /dev/md0
geli attach ....
dd if=/dev/random of=/dev/md0.eli
newfs /dev/md0.eli
detach disk, kldload aesni, attach disk, no errors reported.

 

[`Orum]

When the aesni(4) kernel module is loaded, the console (/var/log/messages) prints the supported AESNI set of instructions the CPU is capable of, is AES-XTS amongs them?

Both AES-XTS and SHA256 are present:

aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS,SHA1,SHA256> on motherboard

I wonder if this is something specific to my hardware (Ryzen 5 2500U) or family of hardware.