-
Problem descriptionWhen using a FDE system that seal the LUKS2 key based on some policy that is linked to the PCRs that are involved in measured boot (lPCR#0 to PCR#4), can be useful to inform to a 3rd party tool that some change happen. For example, if there is an update that will happen during the next boot (via the UEFI capsule), the boot chain will change and the PCR#4 will now be different, as it will include Not addressing this will require from the user to provide the device password (like the recovery key) two times, one when the PCR#4 change, and another one after the second boot and the new firmware is participating in the boot. Proposed solutionIf fwupd trigger a 3rd party tool after an update is done, this tool can check the ESP and measure the fwupdx64.efi file to include it in the TPM2 policy and disable the PCR#0..PCR#3 measurements for the next boot (that can be different for the first next boot, or for the second). A service running in the boot can now recalculate the PCR#4 prediction, dropping the fwupd EFI binary, and this same service during the second boot can now include the PCR#0..PCR#3. I am not well known of fwupd plugin mechanisms, but IIUC they are designed to update devices, and not to have a cross-functional service that can be triggered for any update. Does fwupd support some kind of mechanism like the one described, or there is a mechanism in place that can address this issue? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
We've got various hooks that get run after various things have run -- but can you be a be a bit more specific on what we need to poke when? i.e. "call this dbus method when the update has been deployed to the ESP just before the user reboots" or "run this command when the user has returned back from doing a successful update" -- I suspect a lot of this could be handled in a plugin using the composite_update and composite_cleanup vfuncs. In general I'd like to avoid a |
Beta Was this translation helpful? Give feedback.
-
There are multiple options, and this is about the most naive and simple one: when there is effective update of any component of the boot (firmware, databases), report this to a given script. The script can now measure the new fwupd EFI binary in the ESP and do some other assumptions. In an ideal world fwupd could report to the script those measures, but beside the fwupdx64.efi, that is owned by fwupd, I do not think that it can provide the future measures of the firmware in the system, without some help of the firmware provider.
Basically this, yes.
I will research this.
In any situation when there is a potential change in what it is measured during the boot. IIUC PCR#2 can measure firmware of some pluggable hardware. |
Beta Was this translation helpful? Give feedback.
-
Some vendors do report the new Golden PCR0's for some hardware -- they're the device checksums you might see in the LVFS metadata. Of course that only helps with PCR0.
https://github.com/fwupd/fwupd/blob/main/libfwupdplugin/fu-plugin.h#L56 might help, I'd advise looking how - |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! Thanks a lot for the pointers! One last question (I was digging into the CI), is there a fairly easy way to trigger it while testing? Somehow do a fake update in some controlled environment (like QEMU) and debug the new code. |
Beta Was this translation helpful? Give feedback.
-
It's not easy at the moment with the uefi_capsule backend as there's no much per-system stuff going on (although it's on the TODO!) but it's very easy to use the "test" plugin and use that in self tests or for local testing. I think |
Beta Was this translation helpful? Give feedback.
We've got various hooks that get run after various things have run -- but can you be a be a bit more specific on what we need to poke when? i.e. "call this dbus method when the update has been deployed to the ESP just before the user reboots" or "run this command when the user has returned back from doing a successful update" -- I suspect a lot of this could be handled in a plugin using the composite_update and composite_cleanup vfuncs.
In general I'd like to avoid a
fwupd.hook.dstyle mechanism as it's really unclear what data the hook needs -- e.g. does it need to be run when only for the system firmware is updated, or any UEFI FMP update?