Exception: scripts sourcing/calls within etc/ash_functions continues to use old TRACE functions until we switch to bash completely getting rid of ash.
This would mean getting rid of legacy boards (flash + legacy boards which do not have enough space for bash in flash boards) once and for all.
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
When playing with long fbwhiptail/whiptail messages, this commit played around the long string using fold.
'''
echo -e "This will replace the encrypted container content and its LUKS Disk Recovery Key.\n\nThe passphrase associated with this key will be asked from the user under the following conditions:\n 1-Every boot if no Disk Unlock Key was added to the TPM\n 2-If the TPM fails (hardware failure)\n 3-If the firmware has been tampered with/modified by the user\n\nThis process requires you to type the current LUKS Disk Recovery Key passphrase and will delete the LUKS TPM Disk Unlock Key slot, if set up, by setting a default boot LUKS key slot (1) if present.\n\nAt the next prompt, you may be asked to select which file corresponds to the LUKS device container.\n\nHit Enter to continue." | fold -w 70 -s
'''
Which gave the exact output of what will be inside of the fbwhiptail prompt, fixed to 70 chars width:
'''
This will replace the encrypted container content and its LUKS Disk
Recovery Key.
The passphrase associated with this key will be asked from the user
under the following conditions:
1-Every boot if no Disk Unlock Key was added to the TPM
2-If the TPM fails (hardware failure)
3-If the firmware has been tampered with/modified by the user
This process requires you to type the current LUKS Disk Recovery Key
passphrase and will delete the LUKS TPM Disk Unlock Key slot, if set
up, by setting a default boot LUKS key slot (1) if present.
At the next prompt, you may be asked to select which file corresponds
to the LUKS device container.
Hit Enter to continue.
'''
Therefore, for long prompts in the future, one can just deal with "\n 1-" alignments to be respected in prompts and have fold deal with cutting the length of strings properly.
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
gui-init: do not consume two unseal attempt to unseal both totp and hotp + cosmetic changes (slow down TPM DA lockout)
kexec-seal-key: Add DEBUG statement for PCR precalc
seal-totp: add DEBUG statements regarding skipping of PCR5 and PCR6 involvement into TOTP/HOTP sealing ops
seal-hotpkey: Add DEBUG statements related to reuse of TOTP sealed secret
tpmr: add DO_WITH_DEBUG calls to output pcrread and extend calls
tpmr: typo correction stating TRACE calls for tpm2 where it was for tpm1
tpmr: add DO_WITH_DEBUG calls for calcfuturepcr
functions: Cosmetic fix on pause_recovery asking user to press Enter to go to recovery shell on host console when board defines CONFIG_BOOT_RECOVERY_SERIAL
Not so related but part of output review and corrections:
kexec-insert-key: cosmetic changes prepending "+++" to disk related changes
kexec-save-default: cosmetic changes prepending "+++" to disk related changes
config/coreboot-qemu-tpm*.config: add ccache support for faster coreboot rebuild times
-coreboot support of TPM v2.0 (shared config for TPM2 support across all 4 previous variations)
-swtpm set to be launched under TPM v2.0 mode under board config
-Documentation file under each board.md softlinks to qemu-coreboot-fbwhiptail-tpm1.md (which has been generalized)
This is skeleton for TPM v2 integration under Heads
-------------
WiP
TODO:
- libcurl cannot be built as a tpm2-tools dependency as of now not sure why. curl currently needs to be added in board config to be built
- Note: tpm-reset (master and here) needs some review, no handle of no tpm use case. Caller is responsible to not call it otherwise does nothing
- init tries to bind fd and fails currently
- Note: Check if whiptail is different of fbwhiptail in clearing screen. As of now every clear seems to be removed, still whiptail clears previous console output
- When no OS' /boot can be mounted, do not try to TPM reset (will fail)
- seal-hotpkey is not working properly
- setting disk unlock key asks for TPM ownership passphrase (sealing in NV requires ownership, but text is misleading user as if reowning TPM)
- We should cache input, feed tpm behind the scene and wipe passphrase and state clearly that this is TPM disk unlock kye passphrase.
- primary key from TPM2 is invalid most of the time from kexec-select-boot and verifying global hashes but is setuped correctly at disk unlock key setup
- would be nice to take advantage of bash function tracing to understand where we are for debugging purposes, code takes ash in consideration only
- tpmr says it implements nv calls but actually doesn't. Removing those falsely wrapped functions would help.
- Implementing them would be better
- REVIEW TODOS IN CODE
- READD CIRCLECI CONFIG
Current state:
- TPM unseal works without disk unlock key and generates TOTP properly (was missing die condition at unseal to not produce always good TOTP even if invalid)
- TPM disk encryption key fails. Hypothesis is that sealing with USB drivers loaded and measures in inconsistent with sealed with/without.
- TPM disk unsealing happens without USB modules being loaded in non-HOTP setup. This fails.
- Current tests are with fbwhiptail (no clear called so having traces on command line of what happens)
- Testing with HOTP implementation for sealing/unsealing since that forces USB module loads on each boot to remove this from failing possibilities
- Add TRACE function tracing output under etc/functions, depending on CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT enabled in board configs
- Replace current DEBUG to TRACE calls in code, reserving DEBUG calls for more verbose debugging later on (output of variables etc)
- add 'export CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT=y' in qemu-coreboot(fb)whiptail-tpm1(-hotp) boards to see it in action
- kexec-save-default extracts initrd crypttab files and creates /boot/kexec_initrd_crypttab_overrides.txt entries pointing to /secret.key
- kexec-insert-key applies /boot/kexec_initrd_crypttab_overrides.txt to replace initrd's crypttabs files pointing to inserted /secret.key through cpio
- Both scripts inform the user of applied magic on screen
Not all distro put crypttab under /etc/ within initramfs, but finding it at
runtime needs unpacking, which may be hard to do, so it is made overridable
with a file at /boot/kexec_initrd_crypttab_path.txt, whose content could be
obtained with $ cpio -t < ${uncompressed_initrd} | grep crypttab .
The "target" field of the record within the crypttab stored in the root
file system for the luks container which is going to be unlocked via
kexec-insert-key should be modified into the same "luks-$uuid" format,
otherwise the boot sequence will get stuck when OS is trying to unlock them
again, in order to map them according to "target" fields written in the
crypttab stored in the root fs.
Closes issue #226
Also changed to procedure to show LVM volume groups and block
device ids to aid in choosing the right combination during the
TPM LUKS key sealing process.
