Solved kldload of aesni.ko fails in 13.* releases

D

davhol

I've recently upgraded to FreeBSD13.2 and I'm finding that when trying to load the kernel module, aesni.ko (/boot/loader.conf: aesni_load="YES"), it fails. When I log in as root and try to manually load the module, I get:
Code: 
# kldload /boot/kernel/aesni.ko 
kldload: an error occurred while loading module /boot/kernel/aesni.ko. Please check dmesg(8) for more details.
When I tail dmesg -a, I see:
Code: 
interface aesni.1 already present in the KLD 'kernel'!
linker_load_file: /boot/kernel/aesni.ko - unsupported file type
I've tried this on vanilla installations (default kernel, not custom) of FreeBSD 13.0, 13.1 and 13.2. This used to work in FreeBSD 12.4, 12.3, etc.

I'm loading this module to support the AESNI instructions to speed-up processing with the GELI module for encrypted disk partitions. (I should mention that all the above-mentioned systems/installation instances are under Vmware Fusion (Mac) 13.

This is not a "show-stopper" issue for me/my company, but it does give me pause thinking there may be an issue with the FreeBSD13 branches. Can anyone advise me?

For references, my /boot/loader.conf has, at the top:
Code: 
mfi_load="NO"
mrsas_load="YES"
aesni_load="YES"
cryptodev_load="YES"
geom_eli_load="YES"

Other than the AESNI module, all the other modules load. My system functions but when I boot the system, I see that GEOM_ELI reports "Crypto: Software" rather than the "Crypto: Hardware" I've been seeing in FreeBSD 12. For reference, here is what the kernel reports when it boots (from dmesg -a):
Code: 
CPU: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz (4200.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x906e9  Family=0x6  Model=0x9e  Stepping=9
  Features=0xf83fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS>
  Features2=0xfffa3203<SSE3,PCLMULQDQ,SSSE3,FMA,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,[COLOR=rgb(209, 72, 65)]AESNI[/COLOR],XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x9c27ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,RDSEED,ADX,SMAP,CLFLUSHOPT>
  Structured Extended Features3=0xbc000400<MD_CLEAR,IBPB,STIBP,L1DFL,ARCH_CAP,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  IA32_ARCH_CAPS=0xc<RSBA,SKIP_L1DFL_VME>
  TSC: P-state invariant
As one can see in the "Features2" line above, AESNI is indicated as being available.
 
davhol said:
I've tried this on vanilla installations (default kernel, not custom) of FreeBSD 13.0, 13.1 and 13.2. This used to work in FreeBSD 12.4, 12.3, etc.
Click to expand...
It gets loaded with cryptodev_load on 13.x.

davhol said:
Code: 
mfi_load="NO" 
mrsas_load="YES"
Click to expand...
These don't do anything, both are already included in the GENERIC kernel. Switching to mrsas(4) is done with hw.mfi.mrsas_enable="1" in device.hints:
Code: 
     Using /boot/device.hints (as mentioned below), the user can provide a
     preference for the mrsas driver to detect a MR-Fusion card instead of the
     mfi(4) driver.

           hw.mfi.mrsas_enable="1"
 
Since 13.0-RELEASE the aesni(4) kernel module is already compiled in the GENERIC kernel (see the release notes). The change from Crypto: Hardware to Crypto: Software is only a change in the naming, as also seen in the release notes.

EDIT: change in naming was hardware to accelerated software. I think that still does refer to your message.
 
As the message says it's already loaded.
To verify this you can do: kldstat -v|grep aesni. dmesg also reports this:
Code: 
$ dmesg |grep -i ^aes
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
 
You must log in or register to reply here.
Back
Top