0cef8e1edc
cryptsetup2 2.6.1 is a new release that supports reencryption of Q4.2 release LUKS2 volumes created at installation. This is a critical feature for the Qubes OS 4.2 release for added data at rest protection Cryptsetup 2.6.x internal changes: - 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 permit LUKS key slot specification anymore: key slot rotates (new one consusumed per op: then old one wiped internally. EG: LUKS key slot 1 created, then 0 deleted) - reencryption doesn't permit old call arguments. No more direct-io; inadmissively slow through AIO (async) calls, need workarounds for good enough perfs (arguments + newer kernel with cloudfare fixes in tree) cryptsetup 2.6.1 requires: - lvm2 2.03.23, which is also included in this PR. - requires libaio, which is also included in this PR (could be hacked out but deep dependency at first sight: left in) - requires util-linux 2.39 - patches for reproducible builds are included for above 3 packages. luks-functions was updated to support the new cryptsetup2 version calls/changes - 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 - LUKS container ops now validate Disk Recovery Key (DRK) passphrase prior and DRK key slot prior of going forward if needed, failing early. - Heads don't expect DRK to be in static key slot anymore, and finds the 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 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 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 keys. - It was suggested to leave LUKS key slots outside of DRK alone, but then: what to do when all key slots would be used? - Alternative implementation could be to only prompt users to wipe keyslots 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. - LUKS containers now checked to be same LUKS version prior of permitting to set TPM DUK and will refuse to go forward of different versions. TODO: - 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 already deprecated Unrelated: - typos fixes found along the way Signed-off-by: Thierry Laurion <insurgo@riseup.net> |
||
---|---|---|
.. | ||
UNMAINTAINED_p8z77-m_pro-tpm1-hotp-maximized | ||
UNMAINTAINED_p8z77-m_pro-tpm1-maximized | ||
UNMAINTAINED_qemu-linuxboot | ||
UNMAINTAINED_t420 | ||
UNMAINTAINED_t430-hotp-legacy | ||
UNMAINTAINED_t430-legacy | ||
UNMAINTAINED_t430-legacy-flash | ||
UNMAINTAINED_t520-hotp-maximized | ||
UNMAINTAINED_t520-maximized | ||
UNMAINTAINED_t530-dgpu-hotp-maximized | ||
UNMAINTAINED_t530-dgpu-maximized | ||
UNMAINTAINED_w530-dgpu-K1000m-hotp-maximized | ||
UNMAINTAINED_w530-dgpu-K1000m-maximized | ||
UNMAINTAINED_w530-dgpu-K2000m-hotp-maximized | ||
UNMAINTAINED_w530-dgpu-K2000m-maximized | ||
UNMAINTAINED_x220 | ||
UNMAINTAINED_x230-hotp-legacy | ||
UNMAINTAINED_x230-legacy | ||
UNMAINTAINED_x230-legacy-flash | ||
UNTESTED_leopard | ||
UNTESTED_r630 | ||
UNTESTED_s2600wf | ||
UNTESTED_tioga | ||
UNTESTED_winterfell | ||
x230-hotp-legacy | ||
x230-legacy | ||
x230-legacy-flash | ||
README.md |
Boards listed under this directory are not made available from CircleCI. No .rom file is available for endusers. This is protecting as good as possible regular endusers from having to open up their devices and having to own a SPI-clip and a external flasher. After core changes in coreboot or heads, known testers with external flasher are asked to test a new release and report if their system is starting up fine. If those known testers do not respond, a .rom id made available from CircleCI to the public with addition in filename UNTESTED_ . This invite people with external flasher that could recover a not booting system to report if the release is working fine. Warning: Do not try to use UNTESTED_ images if you do not have a external flasher.
After about a month passes by and there is still no report if the system is starting up fine with the new release, the device is moved to this directory to stop building UNTESTED_ images. Reason for this is because there are always users ignoring all warnings and then asking questions like how to recover a not starting system without external programmer.
To get a device out of this directory and make it at available from CircleCI again, open up a issue here https://github.com/linuxboot/heads/issues and ask for a build for the specific device you like to test or build it youself. When building it yourself, please dont forget to report a working state.
The additional name UNMAINTAINED_ is added to the device name, when maintanance is known needed. When device is UNTESTED_ and someone test and report a not booting image, the device get as soon as possibe moved to this directory and changed from UNTESTED_ to UNMAINTAINED_. Its then tested and not working.
When a device have just the addition UNMAINTAINED_ but is not in this directory and there are CircleCI .rom files available to the endusers, then its tested starting up the system but have some problems like for example not working Network card and there is no maintainer to fix the problem. If a UNMAINTAINED_ device dont get tested on a new release, it follow up the same UNTESTED_ procedure like described above and have UNMAINTAINED_UNTESTED_ in the name.