Adiantum crypto module for CPUs without AES-NI

[natterangell]

The Thinkpad x230i is supported by the x230* roms, and only differs from the regular x230 in that it shipped with a non-upgradable Ivy Bridge i3 CPU which doesn't support AES-NI.

LUKS v2 is compatible with adiantum, developed by Google primarily for low-powered devices that cannot do hardware accelerated AES encryption. It is included from kernel 5.0 and cryptsetup 2.x (not sure what version) supports it.

This software cipher is a lot faster on CPUs without AES-NI.

While this might be an edge case, given that most Heads users will not see much difference due to AES-NI support, it might be worth considering for the x230i, and maybe other boards (i3 x220/t420, others?)

I can build my own rom to test, but I wonder what options must be set for building kernel (and maybe cryptsetup?) with support included? With #1398 merged it should be possible.

[natterangell]

It might seem like the following is enough:
CONFIG_CRYPTO_ADIANTUM=y
CONFIG_CRYPTO_NHPOLY1305=y
CONFIG_CRYPTO_CHACHA20=y

[tlaurion]

@natterangell : Heads uses cryptsetup for two things and is unrelated to what the final OS is providing:

• cryptsetup open operations to unlock container under recovery shell.
• cryptsetup-reencrypt operations, which reuses the current LUKs container settings unless manually instructed to change them.
• TPM disk unlock key addition to LUKS header, unsealed by TPM disk unlock key passphrase with sealed extended measurements of Heads runtime measurements.

To change those LUKS OS installer defaults, the user either has to:

• Manually call cryptsetup-reencrypt under Heads and pass the desired algo options (where Heads would need those additional algos)
• Manually go to shell under OS installer and manually partition the drive at install, make the LUKS container available to the installer and then continue from there, rescanning disk which should pickup mapped container for further partitioning. Again here, your custom chosen algo would need to be supported under Heads as well if Heads support desired for above mentioned purposes.

Now my opinions:

• If this is really desired, we could now duplicate x230 and other boards to point to different linux kernel configs having those crypto options selected. (Note that you are the only reported x230i user, since Heads is mostly used while not limited to QubesOS where i3 do not fill qubesos requirements for virtualization extension and therefore are not chosen by end users if goal is to use QubesOS). I am not aware of any other board owners of xx20 or xx30 which have an i3 vs i5 i7 which have AES-NI vt-x vtd2 for interrupt remapping on those other board models.
• linux-x230-maximized is shared across xx20 and xx30 boards for maintainership simplicity, where xx20 ony have 8mb of flash so adding AES crypto without AES-NI is fine (and merged, we could undo if x230i board is added with specialized kernel config) but readding crypto modules used only by some for corner case situations and where OS installers do not create LUKS containers with those options unless users hack their way into it is really geeeky and I have some reluctance adding those into shared linux-x230-maxized.config where need might be later on to remove it, postponing the issue to be dealt later.
• You can definitely clone x230-maximized board config to x230i-maximized and duplicate linux-x230-maximized.config to linux-x230i-maximized config adding those if you will, specifying under the board config that this device is an i3 for others to use, but AFAIK x230i are pretty rare out there.
• As you might have noticed, calling all board owners when kernel version bump happens is a real burden and boards get relagated to UNTESTED boards recently.

So my question really is: does it really impact real life performances as opposed to memory benchmark tests? Nothing stops you from hacking your way into installing OS with those cryptsetup customized options to install and add those kernel modules into Heads in local modifications to see if there is real gains. Afterall, as noted above, cryptsetup is used to add TPM disk unlock key on default boot option, otherwise leaving the user to type the disk recovery key on OS prompt. If all that work seems relevant, including creating some documentation in heads-wiki for OS installation to instructs users to support that LUKS container creation prior of continuing with installer defaults for others to follow as well, then I'm willing to go in that direction.

Thoughts? PR welcome and prompt testing needed in the future if you are the sole x230i board owner known out there using that customized setup.

[natterangell]

Completely fine with me not to create a separate x230i board. I suspected as much that few (if anyone) use this system, this is a laptop I got more or less for free, and not my main system anyway.

I'll experiment a litte when I get around to it and document in fork whether it works.