Fix TPM DUK retry loop (bogus), uniformize related vocabulary #1595
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
UndeadDevel
reviewed
Jan 19, 2024
JonathonHall-Purism
requested changes
Jan 19, 2024
There was a problem hiding this comment.
Thanks @tlaurion, good find, improvements to wording consistency are great too. Posted a few notes but generally looks good. Not sure if the fix is 100% correct from a read over but made a suggestion, details on kexec-unseal-key.
tlaurion
force-pushed
the
fix_tpm_duk_retry
branch
from
e96673e to
f66dd2b
Compare
…output to check active keyslot 1 is not the only one existing Signed-off-by: Thierry Laurion <[email protected]>
tlaurion
force-pushed
the
fix_tpm_duk_retry
branch
3 times, most recently
from
d701946 to
5a52c67
Compare
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 <[email protected]>
…UG mode/Recovery Shell Next steps on this is introspection and PCRs reconstruction helpers, which will output in DEBUG and be usable from recovery shell. We have to keep in mind that providing those tools is useful in DEBUG mode and for users having access to Recovery Shell. But currently, having access to cbmem -L output and final PCRs content is making it too easy for Evil Maid to know what needs to be hardcoded to pass measured boot. Signed-off-by: Thierry Laurion <[email protected]>
tlaurion
force-pushed
the
fix_tpm_duk_retry
branch
from
5a52c67 to
4f2b1b6
Compare
|
@JonathonHall-Purism Ready for merge? |
JonathonHall-Purism
approved these changes
Jan 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#1588 related: fixes retry. Left behind: capslock key detection and fix.
@JonathonHall-Purism please review
Tested:
Basically, the loop code was bogues because of pipefail, TPM DUK passphrase failing to unseal caused pipefail and exiting without retrying input as codepath expected.
TODO: find a nice way to get capslock state from tty. Only way found as of now would be through kbd, and extracting ioctl call to tty to get state of key modifiers. That is estimated to be 7kb of compiled c code that would need to be an independent app. I have not found any other easy way to get capslock state. Reminder, there is no capslock led on old lenovos, and exposing those leds through kernel modules successfully exposes capclock but since EC firmware doesn't interact in any way with abent leds, the state cannot be read from LEDs so not an alternative solution. If anybody has an idea that could go through exposed /sys /proc or even agetty/stty, I tried a lot but didn't succeed. @JonathonHall-Purism ideas there?