TPM2 is only required to support password lengths up to its longest
hash size (32 chars for sha256). Pass the sha256 of the password
instead of the actual password so the password can be arbitrarily long.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Set flags 'fixedtpm|fixedparent|adminwithpolicy'. Plain password auth
is no longer allowed. For objects sealed with a password, the password
is part of the auth policy, so both PCRs and password must be satisfied
to unseal.
Tested by manually attempting to unseal disk unlock key with password:
tpm2 unseal -c 0x81000003 -p "<password>"
This now correctly returns an error indicating this auth method is not
allowed.
Relative to the documented default flags for tpm2_create:
* sign, decrypt: Not applicable to a sealed object, tpm2_create
automatically removed these from the defaults.
* fixedtpm, fixedparent: Kept
* sensitivedataorigin: Not applicable an object where the sensitive
data is not generated by the TPM.
* userwithauth: Removed this, "user" actions must satisfy auth policy.
* adminwithpolicy: Added this, "admin" actions must satisfy auth
policy.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
After saving a disk unlock key, if debug output is enabled, drop to
a recovery shell to allow inspection of debug output.
The script isn't intended to return from this point after sealing a
key - returning attempts to boot, which can't unseal the key.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Trace parameters to seal/unseal and some key tpm2 invocations. Trace
invocation of tpmr seal/unseal for disk unlock key.
Add DO_WITH_DEBUG() to trace a command and parameters, then execute it.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
When sealing/unsealing with a password, use a policy including both the
specified PCRs and the object password. Fixes sealing and unsealing
disk unlock key.
tpm2 seems to have a bug in parameter decryption when using a policy
session and password in this way, disable encryption in the policy
session as a workaround.
Flags still need to be set on the sealed object correctly, as the
password is normally allowed on its own as an alternative to policy
auth.
Add -Q to some tpm2 invocations to silence diagnostics on stdout.
Pass filename for unsealed secret rather than capturing from stdout
for robustness against tpm2 diagnostics on stdout.
Fix unseal result check in kexec-unseal-key.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
- /tmp/debug.log is created and appended by all TRACE and DEBUG calls in code
- fix some logic errors seen when no DEBUG entry were outputted in /tmp/debug.log
Always send password via stdin to tpm2 create, tpm2 unseal. The password
could being with things like 'file:', 'str:', 'pcr:' that would be
interpreted by tpm2.
Deduplicate the TPM1/2 code in kexec-unseal-key. The TPM2 code was not
actually prompting for the password or sending it to tpmr unseal.
Password is still not working yet though.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Most logic throughout Heads doesn't need to know TPM1 versus TPM2 (and
shouldn't, the differences should be localized). Some checks were
incorrect and are fixed by this change. Most checks are now unchanged
relative to master.
There are not that many places outside of tpmr that need to
differentiate TPM1 and TPM2. Some of those are duplicate code that
should be consolidated (seal-hotpkey, unseal-totp, unseal-hotp), and
some more are probably good candidates for abstracting in tpmr so the
business logic doesn't have to know TPM1 vs. TPM2.
Previously, CONFIG_TPM could be variously 'y', 'n', or empty. Now it
is always 'y' or 'n', and 'y' means "any TPM". Board configs are
unchanged, setting CONFIG_TPM2_TOOLS=y implies CONFIG_TPM=y so this
doesn't have to be duplicated and can't be mistakenly mismatched.
There were a few checks for CONFIG_TPM = n that only coincidentally
worked for TPM2 because CONFIG_TPM was empty (not 'n'). This test is
now OK, but the checks were also cleaned up to '!= "y"' for robustness.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Use common password prompt logic in tpm-reset rather than duplicating
in tpmr reset.
Use common logic in config-gui.sh to reset the TPM.
Use common logic in oem-factory-reset to reset TPM. Fixes extra
prompts for TPM2 owner password even when choosing to use a common
password. Fix sense of "NO TPM" check in TOTP generation (which only
happened to work because CONFIG_TPM is empty for TPM2).
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
$CONFIG_TPM needs to be quoted, or [ syntax is incorrect when it's
empty. Fixes errors in console with TPM2 (but behavior was correct due
to [ still returning false as expected).
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Resetting the TPM creates a new primary object, and there is no reason
for kexec-save-default to sign an old hash. Always update the hash
instead of creating it only if it doesn't exist.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Invoke swtpm_setup --create-config-files skip-if-exist to create local
CA files under the current user account, so user does not need
read/write access to /var/lib/swtpm-localca.
Pass --tpm2 to manufacture a TPM2 instead of TPM1.2.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Resetting the TPM invalidates the primary handle hash, and
kexec-save-default only generates a hash if none exists. Remove the
hash file when it is invalidated.
OEM reset and "Reset Configuration" both already remove all kexec
files.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
The actual use of curl was already removed, update tpm2-tools patch to
also remove the check for curl. Remove the curl module and
CONFIG_CURL.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
-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
This change will improve build times by allowing the T440p to share the
Coreboot 4.17 cache with the Librem boards. Once we update the other
ThinkPad boards to use Coreboot 4.19, we'll make the T440p depend on the
X230 again.
Co-authored-by: Thierry Laurion <insurgo@riseup.net>
Because we're using pushd/popd to make the Coreboot util invocation
cleaner, we need to use realpath so that the scripts will work with any
user input.
Before, the T440p blob scripts would look for Coreboot using the find
command. Now, we require the user to specify the path to Coreboot in the
COREBOOT_DIR environment variable. Also, add an output directory
argument to each script.
These changes will make it easier to integrate with the Heads build
system and CI.
- I extracted the gbe.bin blob from my T440p's original ROM using the
blobs/t440p/extract script.
- Using a hex editor, I corrected the sign bit in part 0 that I found
was malformed in my analysis:
https://github.com/osresearch/heads/pull/1282#issuecomment-1400634600.
- After correcting the sign bit, nvmutil showed that both parts of my
gbe.bin blob had valid checksums.
- Finally, I used nvmutil to set the MAC address to 00🇩🇪ad:c0:ff:ee.
pkg-config will still pick up system default directories from
PKG_CONFIG_LIBDIR even if PKG_CONFIG_PATH is set. Per the docs,
cross compilation requires clearing PKG_CONFIG_PATH and setting
PKG_CONFIG_LIBDIR (which is always searched after PKG_CONFIG_PATH).
Fixes issues observed in tpm2_retry branch picking up packages from
host environment.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
- 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
The calculations outlined at https://github.com/osresearch/heads/pull/1282#discussion_r1072473677
Sums to having 'ifdtool -f layout.txt ifd_shrinked.bin && cat layout.txt'
The example for T440p:
00000000:00000fff fd
00021000:00bfffff bios
00003000:00020fff me
00001000:00002fff gbe
Here: 00bfffff-00021000=BDEFFF
Which is exact result of @rbeslow's calculations.
There is an issue on haswell, maybe because of car, maybe because of non native memory init blob.
But this is not the case for xx20/xx30 boards.
