Cryptsetup toolstack version bump (2.3.3-> 2.6.1) + reencryption cleanup (LUKS v1/v2 proper support + reencryption on Q4.2 + BTRFS dual LUKS containers install)

[tlaurion]

• Bump kernel from 5.10.5 -> 5.10.214

  • Cloudfare patches to speed up LUKS encryption were upstreamed into linux kernel and backported to 5.10.9+.
    • See Inclusion into upstream kernel plans? cloudflare/linux#1 (comment)
  • cryptsetup2 toolstack version bump and script fixes to support multi-LUKS containers (BTRFS QubesOS 4.2)
    • Argon2 used externally and internally: requires a lot of RAM and CPU to derivate passphrase to key validated in key slots.
      • This is used to rate limit efficiently bruteforcing of LUKS key slots, requiring each offline brute force attempt to consume ~15-30 seconds per attempt
      • Of course, strong passphrases are still recommended, but bruteforcing LUKSv2 containers with Argon2 would require immense time, ram and CPU even to bruteforce low entropy passphrase/PINs.
    • passphrase change doesn't reuse LUKS key slot anymore: cryptsetup passhprase change enforces key slot rotattion (new one consusumed per hot operation: the old one wiped internally after change. EG: LUKS key slot 1 created, then 0 deleted)
    • reencryption doesn't permit old call arguments. No more direct-io; inadmissibly slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree)
  • cryptsetup required whole toolstack version bump:
    • cryptsetup requires lvm2 2.03.23+
    • cryptsetup requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in, deprecates all legacy boards)
      • which requires util-linux 2.39
    • patches for reproducible builds are included for above 4 packages.

• luks-functions was updated to support the new cryptsetup 2.6.1 version calls/changes as opposed to old 2.3 in master

  • reencryption happen in direct-io, offline mode and without locking, requiring linux 5.10.9+ to bypass linux queues
    • from tests, this is best for performance and reliability in single-user mode, as before, op cannot be interrupted.
  • LUKS container ops now validate Disk Recovery Key (DRK) passphrase and DRK key slot prior of going forward if needed, failing close early.
    • Heads don't expect DRK to be in static key slot anymore, and finds and keeps track of the used DRK key slot dynamically.
    • If reencrytipn/passphrase change: make sure all LUKS containers on same block device can be unlocked with same DRK
      • Reencryption: requires to know which key slot to reencrypt.
        • Find LUKS key slot that unlocks with DRK passphrase unlock prior of reencrypt call
      • Passphrase change: no slot can be passed, but key slot of DRK rotates.

• kexec-seal-key

  • TPM LUKS Disk Unlock Key key slots have changed to be set in max slots per LUKS version (LUKSv1:7 /LUKSv2: 31)
    • If key slot != default LUKS version's keyslot outside of found DRK key slot: prompt the user before wiping that key slot, otherwise wipe automatically
      • This takes for granted that the DRK key slot alone is needed on the system and Heads solely controls the LUKS key slots.
        • If user has something else going on, ie: Using USB Security dongle + TPM DUK, then the user will need to say no when wiping additional key slot not being DRK or LUKSv1:7/LUKSv2:31.
          • It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used on next op?
            • Alternative implementation could be to only prompt users to wipe key slots other then DRK when key slots are all used (LUKSv1: 0-7, LUKSv2: 0-31)
              • But then cleanup would need to happen prior of operations (LUKS passphrase change, TPM DUK setup) and could be problematic, where OS might fail (QubesOS DRK util doesn't do test on this, not sure why any other user util would also check for that corner case. Was decided against.)
  • LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward if different versions of LUKS found across LUKS containers specified to be unlocked with TPM DUK, even if across different block devices.

---

TODOs:

• async (AIO) calls are not used. direct-io is used instead. libaio could be hacked out
  • this could be subject to future work.

Notes:

• time to deprecated legacy boards the do not enough space for the new space requirements
  • x230-legacy, x230-legacy-flash, x230-hotp-legacy
    • t430-legacy, t430-legacy-flash, t430-hotp-legacy were already deprecated. No more legacy board support
  • None of the legacy boards are now built by CircleCI. Legacy boards are dead, long lived legacy boards.

Unrelated:

• typos fixes found along the way

---

OLD:
I finally got a grip on where stems the problem discussed under #1539

• cryptsesup requires async/sync ops from kernel (removed directio ops)
  • cryptsetup uses direct-io when in offline mode without locking which is new calls changed in luks helper script
• libaio is new strong dependency of lvm2 (hacking needed on lvm2 side to remove dep)
• kernel AIO needed otherwise warning (lets see if that is verbose without being under debug mode later)
• cryptsetup requires newer libdevmapper and dmsetup to deal also with that
• those are provided by newer lvm2 binaries, including blkid and dmsetup itself
  • which required newer util-linux version to provide such

Todo:

• Make sure kernel crypto backend requirements are as small as needed
• Review patches and clean them
• Removeinitrd/test_reencrypt_ram.sh when ramfs raw disk reencryption meets normal speed
• test on real hardware
• legacy boards now deprecated. refactoring of /etc/ash_functions can now occur to depend only on bash
• documentation for deprecation of legacy board
• open other issues, including newer distro impossibilities to having fs reencrypted if done through cryptsetup 2.6.1
• cloudfare optimizations down from cryptsetup calls Choose stronger encryption by default and/or re-use encryption parameters of LUKS container #1539 (comment) still needed?

---

• Disclose publicly needed firmware upgrade/kernel commit bump downstream (that having gone unnoticed confirms that noone reencrypted Q4.2/Q4.2.1 installation up to me discovering this. I can only repeat this, but OEM not pushing users to reencrypt their encrypted drives from OEM means that a malicious worker could backup LUKS header for all laptops where OSes are preinstalled, and sell that LUKS header backup at high prices for daily used laptops theft where OEM provisioned DRK passphrase can then be reused to access FDE content supposedly protected by encryption. The only way to completely transfer OEM ownership of a laptop to the end user is to rerun the Re-Ownership wizard and accept reencrypting the disk. DRK != DRK passphrase. Changing the DRK passphrase won't permit a LUKS header backup/restore from permitting old DRK passphrase from decrypting the FDE content.

---

Old branch prior of cleaning at https://github.com/tlaurion/heads/tree/staging_cryptsetup_261
That was way too much and unexpected work.

[tlaurion]

Oupsies, reencryption happens twice for each luks container. Reviewing.

[tlaurion]

Ready for review. Will address unresolved disscussions points next.

[tlaurion]

The TPM DUK work is, IMO, confusing and I can't really tell from review whether it will work reliably or have issues in corner cases (per comments: #1541 (comment), #1541 (comment)). The UX is also confusing/surprising, not something you usually want when dealing with LUKS encryption keys (#1541 (comment)). I've made suggestions for each of those things. While I try to offer actual changes whenever I can, unfortunately due to internal needs I can't allocate more time toward this feature we don't ship right now.

But like I said, I won't block based on those things.

So, up to you @tlaurion whether you want to merge as-is or work on those suggestions, feel free to discuss further though if you'd like.

I refactored and replied in threads of dscussions. Please review again @JonathonHall-Purism.
The problem today is that fedora 37+/cryptsetup 2.6+ created LUKS containers cannot be reencrypted/passphrase changed with older cryptsetup (Heads master has 2.3.3)

If there is areas of work outside of left todo in last commit (attempt to unlock luks containers with cached LUKS DRK pasphrase), please let me know and i'll open a seperate issue for working this further, but I think that what was blocking this PR was since then addressed.

OEM shipped OS installations should be reencrypted/passphrase changed by user through re-ownership wizard, which cannot happen for a while unless this PR is merged.

Also note that videorecording for end users, made by oems, are expected to be recorded, ideally prior of #1821. So GUI changes should happen sooner then later so that those recordings can be done. Otherwise, either recordings will need to be redone or fixes postponed to next downstream releases

[JonathonHall-Purism]

Thanks @tlaurion. This implementation makes much more sense, and I think the UX is clearer too. Looks good to me 👍