geli(8) is the interface to FreeBSD’s preferred drive encryption system, similar in practical operation to LUKS on Linux, and cgdconfig on NetBSD as I’ve recently learned. It can use the aesni(4) kernel driver to interface with AES-NI on compatible CPUs for better performance, or it performs cryptographic functions in software.
To use it you want to enable the appropriate drivers in /boot/loader.conf:
Then check whether your CPU supports AES-NI by looking at dmesg(8):
# grep AES /var/run/dmesg.boot
You should see something similar to the following:
Features2=[...]AESNI[...] aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> on motherboard GEOM_ELI: Encryption: AES-XTS 256
If not, geli will continue to attach your devices but will warn you of your ancient hardware that you haven’t got around to replacing cough, or your hypervisor isn’t passing through AES-NI to its guests:
aesni0: No AES or SHA support. GEOM_ELI: Encryption: AES-XTS 256
Once you’ve attached your geli devices, you can inspect geli list to check how the crypto is being performed. For example, this is one of my Xeon Microservers:
Geom name: gpt/<SERIAL>.eli State: ACTIVE EncryptionAlgorithm: AES-XTS KeyLength: 256 Crypto: hardware Version: 7
And here’s a drive attached to my Celeron Microserver box that I should get around to rebuilding one day with AES-XTS. Note the use of software for crypto:
Geom name: gptid/<SERIAL>.eli State: ACTIVE EncryptionAlgorithm: AES-CBC KeyLength: 192 Crypto: software Version: 7
I’m not aware of a circumstance where AES-NI exists, aesni and geom_eli is loaded, and geli will still elect to preference software crypto, but I’d defer to the maintainers to say conclusively.