Don't drop MokListTrusted events on image PCR combination #62
Conversation
This file contains hidden or 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
While combining image PCRs, event_subtree would return earlier than desired. As TPMEventID::Pcr14MokListTrusted was the last, event_id.next()? would simply return None, instead of returning the Node (containing the MokListTrusted) that was being cooked at that iteration. That resulted on all MokListTrusted events being dropped from any possible Pcr combination result. Instead of dealing with the event_subtree logic, this commit adds a tail/last TPMEventID case: PcrLastNodeEvent, which is supposed to stay as the last possible option. That way, it won't be during the MokListTrusted iteration, but on the next one that it will return None, not early, but on time this time. Signed-off-by: Beñat Gartzia Arruabarrena <[email protected]>
Member
|
I don't fully follow the logic. Do we have a fully example with all PCR values? If not can you add one? |
No test was covering the scenario in which all pcrs were combined together. Now it adds a test in which bootloader+kernel upgrade is simulated; without secure boot or mok variable updates. This should also help verify that MokListTrusted is not being dropped when combining images together. Signed-off-by: Beñat Gartzia Arruabarrena <[email protected]>
Contributor
Author
|
Yes, it's a rather hacky fix I have to admit. We didn't have one, but I just added a combine test that takes two images with differing grub and kernel while taking into account all pcrs under consideration (4, 7 and 14). |
bgartzi
added a commit
to bgartzi/cocl-operator
that referenced
this pull request
Jan 15, 2026
It's impacted by a known compute-pcrs' combine logic bug: MokListTrusted
events are dropped during PCR combination. A fix is on its way:
trusted-execution-clusters/compute-pcrs#62
While it's merged, let's pretend the wrong pcr14 value is what we are
expecting just to get that green check.
bgartzi
added a commit
to bgartzi/cocl-operator
that referenced
this pull request
Jan 16, 2026
It's impacted by a known compute-pcrs' combine logic bug: MokListTrusted
events are dropped during PCR combination. A fix is on its way:
trusted-execution-clusters/compute-pcrs#62
While it's merged, let's pretend the wrong pcr14 value is what we are
expecting just to get that green check.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
While combining image PCRs, event_subtree would return earlier than desired. As
TPMEventID::Pcr14MokListTrustedwas the last,event_id.next()?would simply returnNone, instead of returning the Node (containing the MokListTrusted) that was being cooked at that iteration.That resulted on all MokListTrusted events being dropped from any possible Pcr combination result.
Instead of dealing with the
event_subtreelogic, this commit adds a tail/lastTPMEventID case: PcrLastNodeEvent, which is supposed to stay as the last possible option. That way, it won't be during the MokListTrusted iteration, but on the next one that it will return None, not early, but on time this time.