Feature request: Enable CONFIG_CRYPTO_ADIANTUM kernel module for LUKS volume support

[arcybiskup]

I recently upgraded to OrbStack 2.2.1 and the new USB passthrough feature is exactly what I needed to replace my UTM + Alpine + SMB setup for working with external drives containing Linux filesystems. The goal is simple: attach a USB drive, unlock a LUKS volume, mount it, and access the files from macOS through ~/OrbStack without the SMB overhead. For ext4, btrfs, and xfs volumes encrypted with the default aes-xts-plain64 cipher, everything works perfectly. dm-crypt loads fine, xts(aes) is available, and all three filesystems are present as built-in or loadable modules.
The problem is that some of my LUKS volumes use the Adiantum cipher instead of AES. These volumes were created on a headless Debian file server running on a Mac Mini with a Core 2 Duo processor, which lacks AES-NI. On that hardware, AES-based encryption is prohibitively slow for large storage arrays, so Adiantum (designed specifically for CPUs without hardware AES acceleration) is the only practical option.
When I try to open these volumes on OrbStack with cryptsetup luksOpen, it fails because the kernel has no Adiantum support:

$ sudo modprobe adiantum
modprobe: module adiantum not found in modules.dep

I confirmed that CONFIG_CRYPTO_ADIANTUM is not set in the OrbStack kernel. The dependent modules (xchacha12, xchacha20, poly1305, nhpoly1305) would also need to be included, though most of the underlying primitives like chacha20 and poly1305 are already present in /proc/crypto.
This is a small ask in terms of kernel config. Adding CONFIG_CRYPTO_ADIANTUM=m along with CONFIG_CRYPTO_NHPOLY1305=m to the defconfig would make these available as loadable modules with zero impact on users who don't need them. The modules would only be loaded on demand when cryptsetup encounters an Adiantum-encrypted volume.
I understand this is a niche use case. Adiantum exists primarily for hardware without AES acceleration, which is not the typical OrbStack user's situation. But the whole point of USB passthrough is interoperability with real-world hardware and storage, and that sometimes means dealing with volumes that were created under different constraints than the machine you're currently working on.
For reference, I verified the current state of crypto support on a fresh Alpine machine in OrbStack 2.2.1 (kernel 7.0.x). dm-crypt, aes, xts(aes), chacha20, xchacha20, poly1305 are all present. Only adiantum and nhpoly1305 are missing.