linux-x230-maximized: readd CONFIG_CRYPTO_AES for x230i since i3 doesn't have INTEL AES NI cpu acceleration.

[tlaurion]

@natterangell Should fix #1472.

Todo:

• @natterangell confirming that it resolves the issue otherwise investigating Review kernel crypto backend requirements #1396 with cryptsetup benchmark on his laptop (Please tet x230-maximized roms produced by this PR under "Checks")
• compare sizes.txt to expose compressed cost of CONFIG_CRYPTO_AES

[natterangell]

WIth heads-x230-maximized-v0.2.0-1752-g5bf14d2.rom it now seems to work as expected! :) Heads can open the volume and seal with TPM.

Debian still asks for the password when booting though (in addition). Is that expected behaviour? I do have encrypted swap, not sure if that affects it(?)

[tlaurion]

WIth heads-x230-maximized-v0.2.0-1752-g5bf14d2.rom it now seems to work as expected! :) Heads can open the volume and seal with TPM.

Debian still asks for the password when booting though (in addition). Is that expected behaviour? I do have encrypted swap, not sure if that affects it(?)

It all depends on the partition scheme. If using BRTFS (same as if using BRTFS under Qubes 4.1+ partition scheme) then two LUKS containers are expected to be unlocked from the TPM disk unlock key. So you should go back into Boot options -> show boot options -> save as default, and answer yes to reseal TPM disk unlock key. But this time, pass the two LUKS containers (eg /dev/sda2 /dev/sda3). Qubes default TLVM partition scheme has it all under a single LUKS container. I guess the information under https://osresearch.net/InstallingOS/#compatibility is not specific enough and could be improved, or the code could suggest found LUKS partitions only to confuse less the user.... Note that BRTFS is not supported within Heads. Only ext4 and TLVM (Thin LVM volume support without thin-lvm-tools). If needs be and tangent is to go torward XFS and BRTFS, we could try to add those tools as well. Note that #1446 is adding support for EXT4 repair tools and ExFat repair tools as well which is now the default for bought sdcards and thumb drives, where Thin LVMs are more and more despised for their added complexity which slows down disk operations.

Also, I'm not sure if https://osresearch.net/InstallingOS/#default-boot-and-disk-unlock is true anymore, since my testing with Talos II and debian invalidates the statement there saying that init doesn't process crypttab: it does, otherwise I would not be able to boot into my OS. @krystian-hebel you reported something similar. What is your partition scheme on Talos II's debian install?

The magic happening in the background here is:

• Heads tries to extract OS initrd and find crypttab there.
• if found, it reuses the UUID there and overrides the config pointing to LUKS key for that entry(ies)
• It creates a secret.cpio containing crypttab override file and the secret used to unlock the LUKS container(s)
• It kexec to the final OS, passing that additional cpio in memory to be extracted on top of initramfs memory
• The OS goes through its normal init script, checks crypttab and attempts to use exposed crypttab file.

@natterangell : So if only one LUKS container is overriden out of many, the final OS will ask for as many LUKS container it doesn't know how to unlock. Let me know if specifying both LUKS containers when setuping a TPM disk unlock key worked (it should: the logic parses those entries and will fail if the partition provided is not a LUKS drive, otherwise leaving slot 0 untouched (disk recovery key) and kills slot1 and then replaces slot 1 with the in-memory generated key corresponding to sealed secret in TPM, which TPM disk unlock key is unsealed with sealed measurements and NV region passphrase. This is why you type a different passphrase on Heads (TPM NV region passphrase to unlock TPM disk unlock key) then on Final OS (Disk recovery key). Hope this clarified everything. Would appreciate if you could do a PR on heads-wiki if that information is unclear to you.

---

Related: asked question to @marmarek at https://forum.qubes-os.org/t/btrfs-and-qubes-os/6967/28 to see if BRTFS was expected to become the default partition scheme over current TLVM default, since QubesOS is first citizen of Heads. But if all OSes are moving away of TLVM, Heads will need to choose what to support in kernel and on filesystem tools provided for recovery shell. Heads cannot support everything since we are limited in ROM space (until we can switch to squashfs/overlayfs, when: undefined).

[tlaurion]

Space comparison between master and this PR's sizes.txt files for x230-maximized boards

Replication notes:

user@heads-tests-deb12:/tmp$ wget https://output.circle-artifacts.com/output/job/618e2a7a-3845-437b-a7b6-64ddc3f2b701/artifacts/0/build/x86/x230-maximized/sizes.txt -O master -q
user@heads-tests-deb12:/tmp$ wget https://output.circle-artifacts.com/output/job/99cfccf6-95b0-41af-ab2a-5cecddfa6468/artifacts/0/build/x86/x230-maximized/sizes.txt -O 1473 -q
user@heads-tests-deb12:/tmp$ diff -u master 1473
--- master	2023-08-16 15:52:19.000000000 -0400
+++ 1473	2023-08-22 09:42:25.000000000 -0400
@@ -1,5 +1,5 @@
-2023-08-16 15:51:32-04:00 6e31163121d1d600047df859844ab8408cc53d2a clean
- 2480256:/root/project/build/x86/x230-maximized/bzImage
+2023-08-22 09:41:44-04:00 5bf14d27de1fb4dd9d2660c159ef11c7c32dac24 clean
+ 2486400:/root/project/build/x86/x230-maximized/bzImage
   685056:/root/project/build/x86/x230-maximized/modules.cpio
 -----
   304040:./lib/modules/e1000e.ko
@@ -144,5 +144,5 @@
      924:./sbin/config-dhcp.sh
     1064:./sbin/insmod
 -----
- 4211200:build/x86/x230-maximized/initrd.cpio.xz
-12582912:/root/project/build/x86/x230-maximized/heads-x230-maximized-v0.2.0-1751-g6e31163.rom
+ 4210688:build/x86/x230-maximized/initrd.cpio.xz
+12582912:/root/project/build/x86/x230-maximized/heads-x230-maximized-v0.2.0-1752-g5bf14d2.rom

[tlaurion]

And now some digging into the numbers from previous post:

• initrd decreased (modules.cpio, tools.cpio and heads.cpio didn't change?!
  • 4211200-4210688=512 of gained space
• kernel increase in size from AES kernel module addition:
  • 2480256-2486400=-6144 of lost space
• Total lost space 512-6144=-5632 bytes

We don't care for maximized boards though:

"/root/project/build/x86/coreboot-4.19/x230-maximized/cbfstool" "/root/project/build/x86/coreboot-4.19/x230-maximized/coreboot.rom" print
FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs_master_header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           93288 none
cpu_microcode_blob.bin         0x16d80    microcode       26624 none
fallback/ramstage              0x1d5c0    stage          130520 LZMA (290168 decompressed)
config                         0x3d400    raw              3257 LZMA (10315 decompressed)
revision                       0x3e100    raw               724 none
build_info                     0x3e400    raw               101 none
bootsplash.jpg                 0x3e4c0    bootsplash      32804 none
fallback/dsdt.aml              0x46540    raw             14522 none
vbt.bin                        0x49e40    raw              1433 LZMA (4281 decompressed)
cmos_layout.bin                0x4a440    cmos_layout      2012 none
fallback/postcar               0x4ac80    stage           39580 none
fallback/payload               0x54780    simple elf    6687999 none
(empty)                        0x6b54c0   null          5316772 none
bootblock                      0xbc7580   bootblock       34880 none
2023-08-22 09:42:18-04:00 INSTALL   build/x86/coreboot-4.19/x230-maximized/coreboot.rom => build/x86/x230-maximized/heads-x230-maximized-v0.2.0-1752-g5bf14d2.rom

Where after merging this, we still have 5316772 bytes in the empt region of CBFS for x230-maximized board and a little less for x230-maximized-hotp but still plenty enough.

Note that legacy boards now has a new discrepency when compared to maximized boards, wich I will just carry along in next linux kernel version bumps.

[natterangell]

WIth heads-x230-maximized-v0.2.0-1752-g5bf14d2.rom it now seems to work as expected! :) Heads can open the volume and seal with TPM.
Debian still asks for the password when booting though (in addition). Is that expected behaviour? I do have encrypted swap, not sure if that affects it(?)

...

Also, I'm not sure if https://osresearch.net/InstallingOS/#default-boot-and-disk-unlock is true anymore, since my testing with Talos II and debian invalidates the statement there saying that init doesn't process crypttab: it does, otherwise I would not be a
ble to boot into my OS.

Actually, I forgot about that wiki entry! Editing /etc/crypttab as described worked! Now the disk boots without additional password entry.

@natterangell : So if only one LUKS container is overriden out of many, the final OS will ask for as many LUKS container it doesn't know how to unlock. Let me know if specifying both LUKS containers when setuping a TPM disk unlock key worked (it should: the logic parses those entries and will fail if the partition provided is not a LUKS drive, otherwise leaving slot 0 untouched (disk recovery key) and kills slot1 and then replaces slot 1 with the in-memory generated key corresponding to sealed secret in TPM, which TPM disk unlock key is unsealed with sealed measurements and NV region passphrase. This is why you type a different passphrase on Heads (TPM NV region passphrase to unlock TPM disk unlock key) then on Final OS (Disk recovery key). Hope this clarified everything. Would appreciate if you could do a PR on heads-wiki if that information is unclear to you.

The encrypted swap is part of the same default volume group, so it unlocks fine along with / after adjusting crypttab. So the wiki works fine for Debian.

All is well! Thank you @tlaurion

[tlaurion]

@natterangell please describe what was wrong on Debian (11? 12?) crypttab file? Was non-existent? I'm asking since, just as qubesos doesn't have a default crypttab, Heads generated one. It means that the one generated for Debian in your case doesn't support expected format. :/

Which version of Debian once again?

[natterangell]

Debian 12 "Bookworm", default encrypted install with LVM.

As mentioned here:

(*) Ubuntu/Debian Note: These systems don’t read /etc/crypttab in their initrd, so you need to adjust the crypttab in the OS and update-initramfs -u to have it attempt to use the injected key. Due to oddities in the cryptroot hooks, you also need keyscript to be in /etc/crypttab even as a no-op /bin/cat:

sda5_crypt UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /secret.key luks,keyscript=/bin/cat_

The vanilla file as installed by Debian looks like this:

sda5_crypt UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none luks,discard

Replacing "none" with "/secret.key", and adding "keyscript=/bin/cat" at the end of the line as described in wiki, then update-initramfs -u and resigning/reseal in Heads unlocks the disk without the need to re-enter password during boot.