feat: minimal poc for TPM measurements à la sd-stub #167
No reviewers
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: raito/lanzaboote#167
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "sd-stub-tpm2"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Depends on #166.Implements TPM part of https://github.com/nix-community/lanzaboote/issues/94.
Note to maintainers & reviewers
Lanzaboote customization requires a special handling of PCR11 measurements to include kernel and initrd properly.
To do this, we need to read the kernel and the initrd guarded with our hashes, then record them as "fake unified section" or measure them somewhere else.
This way, we can slowly recover lanzaboote as a "true UKI" in terms of semantics.
This is out of scope for this PR, but will done in #169 because they do bring the necessary infrastructure wrt to UnifiedSection to perform this.
I'm not so sure about hard failing here.
@RaitoBezarius It would be helpful to have a call one of these days about what's going on in these PRs to give some overview information. :)
When are you available :) ?
@ -0,0 +24,4 @@
// safe, because we don't touch any data in the data sections that
// might conceivably change while we look at the slice.
// (data sections := all unified sections that can be measured.)
let pe_binary = unsafe { image.as_slice() };
add
// SAFETY
I met with @nikstur on the last NixOS Munich meetup and we discussed this PR.
@ -0,0 +2,4 @@
/// UKI specification.
/// This is the canonical order in which they are measured into TPM
/// PCR 11.
/// !!! DO NOT REORDER !!!
Perhaps adding
#[repr(u8)]
and a unit test that checks their order would be nice?std::mem::discriminant
could also be used, perhapsLooks good. Thank you for the work!
I'd love
cargo fmt
Only the code formatting is a blocker for me.
It feels like we shouldn't. Under what circumstances can this fail?
Shouldn't we just not measure anything if there is no TPM available? i.e. only call
measure_image
in thisif
clause.Awesome, will fix the code formatting. :)
Good point!
@ -0,0 +2,4 @@
/// UKI specification.
/// This is the canonical order in which they are measured into TPM
/// PCR 11.
/// !!! DO NOT REORDER !!!
Hmm, I'm not so sure how to do it, I will go ahead and merge this, can you open a PR to propose something?
When we fail to parse our own memory as a PE for example, I'd say
We don't want people doing strange things to the system making us fragile to security, so I'd say hardfailing here is not too shocking but… difficult to say.
We can "not hard fail" then re-evaluate a "extreme stub mode" that tries to thwart active attacks.
This way it's not as easy to get the values wrong by just changing the ordering
@ -0,0 +2,4 @@
/// UKI specification.
/// This is the canonical order in which they are measured into TPM
/// PCR 11.
/// !!! DO NOT REORDER !!!
Added a suggestion :)
Oh I see your point now
Should we merge https://github.com/nix-community/lanzaboote/pull/177 first? This might make formatting easier and the diff easier to read.
Sure thing, this PR has problem with TPM2 protocol being located in UEFI
anyway.
Le jeu. 18 mai 2023 à 16:48, nikstur @.***> a écrit :
OVMF has no TPM support compiled by default, I am fixing that.
@ -0,0 +2,4 @@
/// UKI specification.
/// This is the canonical order in which they are measured into TPM
/// PCR 11.
/// !!! DO NOT REORDER !!!
Applied :)
Formatted and test fixed now.