WIP: UKI+systemdboot pcr4 predictions#78
Conversation
bgartzi
force-pushed
the
systemdboot
branch
3 times, most recently
from
5a55b14 to
75a2ebf
Compare
| //TODO: should we create another TPMEG_ for systemdboot? | ||
| TPMEventID::Pcr4SystemdBoot => TPMEG_BOOTLOADER, |
There was a problem hiding this comment.
I'm wondering if we really need to distinguish things here. They should all behave the same for PCR computation?
There was a problem hiding this comment.
Do you refer to systemdboot from shim/grub? Are you referring to uki/addons and linux too? Could you elaborate your concern a bit more?
I really need to consider how this gears into the combine logic. I just mocked the "I'm running shim/grub and I upgrade into systemdboot" case but did not result in what I'd expect... combine.rs probably needs yet another tweak (or two).
|
We'll need to figure out how to offer an interface to measure all UKI addons (to generate metadata for example) but only include some for the PCR computation. |
Some images might boot from an UKI. By default, it will be located under /boot/EFI/Linux/uki.efi in fedora images. If the user provides another path, that will preceed over it. Now, when new rootfs are created it will check if the user-provided or the default UKI exists. If it does, it will fill the uki + addon fields of the rootfs struct. Later, we can retrieve those. uki returns an Option<String> to know if it is or not a uki image. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
PCR computation for PCR4 with uki or without it was not so different. The only thing that changes is part related to vmlinuz or the UKI. Merge both of them, as we can know which of the cases we are dealing with easily, based on whether the UKI was found in the expected path or not. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Admit paths to the UKI and its addons. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Now users can pass uki and uki addons paths to the compute-pcrs binary. Now, the binary will assume that it is predicting PCRs for an UKI image. It will try to find the UKI image in the path provided by the user. If it was not provided, it will try finding it in the default path. It it was not found even there, then it will assume it is the legacy case and will compute pcr4 as it was done until now. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Find systemd-boot efi file if any and let others know whether it exists or not. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Not there yet. We need to figure out which TPMEG this event should really use. We need to discuss how would this behave in upgrade scenarios. Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
For a very specific case, see: https://github.com/trusted-execution-clusters/fedora-coreos-uki Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
Signed-off-by: Beñat Gartzia Arruabarrena <bgartzia@redhat.com>
The user (or the system using this as a tool) can filter the UKI addons that should go into pcr4 and just pass those to the tool. What is that metadata for? What does it need, the authenticode hash of each of the addons? I guess we could add another command that could create that kind of information receiving the full list of addons? |
2 participants
Very slightly tested. Don't rely on this at this stage by any means.
Depends on #33