Rebuilding the kernel with CRYPTO_AES_NI_INTEL=y (and for that matter CRYPTO_PCRYPT=y) produces the expected result (ie, hw-encryption) - even in the...
FS (say, ext4) stacked on LV stacked on VG stacked on PV stacked on dm-crypt blockdev stacked on partition ... case (which, now that I have a "working" setup, I've since switched back to using). So perhaps the right thing to do is to provide a _very_ early hook to modprobe arch-specific crypto modules (at least, until the crypto folk implement some kind of runtime patching) ? I see that... /usr/share/initramfs-tools/scripts/local-top/cryptroot ... already contains... activate_evms(): for module in ... ; do modprobe -q $module; done ... as well as later on... setup_mapping(): modprobe -q dm_crypt ... so we're already dealing with the readily identifiable/ predictable topologies, and their dependancies. Perhaps we could grow a configurable* (in /etc/default or /etc/initramfs-tools/conf.d/ or elsewhere) which would let us shoot ourselves in the foot with happy abandon? Please let me know if such a beast already exists - it's completely possible I'm just too dense to see where. * nb: I just don't see much point in adding auto-detect logic for these cases myself (it'll just add to the maintenance burden and create failure modes where we need it least - this is the rootfs and swap we're talking about here). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
