fix broken OEM re-ownership process #1357
Merged
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
Problem When using a custom password for TPM, the OEM re-ownership process is broken Impact The OEM re-ownership process breaks for any user setting a custom password and not just using 12345678 First appeared linuxboot@6923fb5 Detail on line 498, if blank, the TPM custom password is overwritten with TPM_PASS_DEF (eg, when no custom password is set by the user installing) ``` if [ "$TPM_PASS" == "" ]; then TPM_PASS=$TPM_PASS_DEF; fi ``` so far so good. $TPM_PASS should be used for all TPM interaction from this point. $TMP_PASS_DEF is now a disposed of variable. we see that happens when resetting the TPM on line 712 (generate_checksums) is that $TPM_PASS is used (correctly) ```## reset TPM and set password if [ "$CONFIG_TPM" = "y" ]; then echo -e "\nResetting TPM...\n" tpmr reset "$TPM_PASS" >/dev/null 2>/tmp/error ---SNIP ``` The TPM now has either the custom password of the user, or the default of 12345678 depending on user selection. On line 712, we duck into the generate_checksums sub, which for some reason reverts to TPM_PASS_DEF ``` # create Heads TPM counter if [ "$CONFIG_TPM" = "y" ];then if [ "$CONFIG_IGNORE_ROLLBACK" != "y" ]; then tpmr counter_create \ -pwdo "$TPM_PASS_DEF" \ --SNIP ``` This then, rightly, fails due to ``` Authentication failed (Incorrect Password) (ox1) from TPM_CreateCounter ```
Closed
|
Nasty.... And a reminder for testing things outside of qemu :/ (which fails injecting key in firmware because #1203) Testing now. Not sure how that landed in master (my bad, sorry about that.) |
As I say to my teams, cant test for every possibility of every combination of every change. we would not progress as we would be doing nothing but testing all the time. The tpm2 changes were a large change set, so small bugs are expected . keep up the good work sir. |
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.
Problem
When using a custom password for TPM, the OEM re-ownership process is broken
Impact
The OEM re-ownership process breaks for any user setting a custom password and not just using 12345678
First appeared
6923fb5
Detail
on line 498, if blank, the TPM custom password is overwritten with TPM_PASS_DEF (eg, when no custom password is set by the user installing)
so far so good. $TPM_PASS should be used for all TPM interaction from this point. $TMP_PASS_DEF is now a disposed of variable.
we see that happens when resetting the TPM on line 712 (generate_checksums) is that $TPM_PASS is used (correctly)
The TPM now has either the custom password of the user, or the default of 12345678 depending on user selection.
On line 712, we duck into the generate_checksums sub, which for some reason reverts to TPM_PASS_DEF
This then, rightly, fails due to