mirror of
https://github.com/u-boot/u-boot.git
synced 2025-04-17 18:34:42 +00:00
011f015540
Currently we only read the pcr updates once on test_tpm2_pcr_read(). It turns out that the tpm init sequence of force_init() which consists of: - tpm2 init - tpm2 startup TPM2_SU_CLEAR - tpm2 self_test full - tpm2 clear TPM2_RH_LOCKOUT also counts as an update. Running this in the console verifies the update bump => tpm2 init => tpm2 startup TPM2_SU_CLEAR => tpm2 self_test full => tpm pcr_read 10 $loadaddr PCR #10 content (28 known updates): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => tpm2 clear TPM2_RH_LOCKOUT => tpm pcr_read 10 $loadaddr PCR #10 content (29 known updates): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 => With the recent changes of replacing 'tpm2 init' with 'tpm2 autostart' we end up always running the full init. The reason is 'tpm init' returns -EBUSY if the tpm is already open, while 'tpm autostart' handles ths gracefully and continues with the initialization. It's worth noting that this won't affect the device functionality at all since retriggering the startup sequence and selftests has no side effects. Instead of relying on the initial value, reread the 'known updates' just before updating the PCR to ensure we read the correct values before testing Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitignore | ||
| conftest.py | ||
| multiplexed_log.css | ||
| multiplexed_log.py | ||
| pytest.ini | ||
| requirements.txt | ||
| test.py | ||
| u_boot_console_base.py | ||
| u_boot_console_exec_attach.py | ||
| u_boot_console_sandbox.py | ||
| u_boot_spawn.py | ||
| u_boot_utils.py | ||