Test measurement

^^^ that's from live session

From **installed** system

this is from removing the usb from the boot order as requested

this is from removing the usb from the boot order as requested

>> it's journal and bios measurements from initrd from a clean boot of a failing unseal

This is from the LIVE SESSION after the installation has completed

This is from the LIVE SESSION after the installation has completed

There's 2 things here that trip us up:
- PCR 4 contains the load events related to the firmware UI in pre-OS environment. In order to support the presence of system preparation applications (those configured by the SysPrepOrder and SysPrepXXXX global variables) which are loaded in the pre-OS environment, we just copy these load events from the log to the profile which is obviously wrong in this case because we don't want the events related to the loading of the firmware UI. The fix for this will be to drop any load event with a path that doesn't match to a corresponding SysPrepXXXX variable that is part of SysPrepOrder. That's going to be easy in most cases because those variables generally aren't going to be set anyway.

- However, this alone still won't work. This device is measuring the launch of Absolute in the pre-OS environment (which is actually the correct place for it - hi to Dell who seem to get this wrong by loading it as part of the OS-present environment, which initially tripped us up because we dropped all events from the log in the OS-present environment based on the assumption that shim would be the first thing to load, and for which we pre-calculate the measurement accordingly. We have a fix for this now to identify an OS-present load event before shim that is related to Absolute and then copying this directly to the profile). The above fix to omit the load events for the firmware UI would also omit the load event for Absolute from the profile because it's in the pre-OS environment and isn't a system preparation application so it will be treated as a component of the firmware UI, which we obviously don't want to do because Absolute will load on normal boots. We will use our existing code to identify a load event as being related to Absolute (they all have the same FvFile name GUID) to ensure that if this appears in the pre-OS environment then it will get copied to the profile - although the recommendation is still to disable Absolute in the firmware UI if there's an option to do that.

This firmware also has a bit of a "yikes" kind of bug. It's loading a UEFI driver from an option ROM that is authenticated with the "HP UEFI Secure Boot DB 2017" CA which seems to be present in db. The EV_EFI_VARIABLE_AUTHORITY event associated with the authentication of this driver must be measured to PCR7, where all secure boot policy goes. One must be able to look at the log for PCR7 in order to determine which CAs authenticated non-platform code that executed, but this device is measuring the authentication event to PCR2 which is very wrong. PCR2 does correctly contain the load event for the driver, but the secure boot event (EV_EFI_VARIABLE_AUTHORITY) should not be in there.

Incidentally, I'm curious what device this driver is coming from. Can I see the output of lspci from this device?

Out of curiosity, I'd also like to see the output of "fwupdmgr get-devices" for this device.

I don't know whether HP can fix this firmware bug, but otherwise we're going to have to add a quirk to secboot to ensure that we include PCR2 to complement PCR7 if we detect any secure boot related events in the former, as this bug significantly degrades the usefulness of PCR7 on its own.

Incidentally, here's the first log attached to this bug in a slightly nicer form: https://paste.ubuntu.com/p/9JwV32FFqc/

The installed system log attached to comment #3 is a bit strange - it still shows the loading going via the firmware UI. Did you enter the firmware UI to change the boot order to load from the internal drive? https://paste.ubuntu.com/p/RJmcbzgGT6/

Comment #5 mentions removing USB from the boot order, but it has no effect - it's still there, probably autogenerated by the firmware. That's not really relevant to this bug though https://paste.ubuntu.com/p/GZcZy9zBBD/

The last log in comment #7 from the live session after install has finished also shows the boot going via the firmware UI. Is it possible to produce a log from a boot on this device that does not go via the firmware UI (or contain events that suggest the firmware UI is being executed). Ie, can you do a normal (non-encrypted) Ubuntu desktop install, boot it as normal and grab the log from that?

Oh, I'm mistaken - the log in comment #5 shows a boot that doesn't go via the firmware UI, and the log looks exactly as I would expect it to look. I can start working on a fix for it then (you can ignore comment #16).

This device still won't work though because the firmware has a debugging endpoint enabled (as indicated by the presence of the EV_EFI_ACTION "UEFI Debug Mode" event measured to PCR7, which means we'll mis-predict PCR7 as well). This device would fail our pre-install checks as being unsuitable for FDE when they land because you can literally just attach a debugger with a gdbserver front end to this in order to use gdb to break, single step, read and write to memory and do whatever else you can do with a debugger, but for now, you'll still just get asked for a recovery key even after I land the fixes for PCR4. What device is this?

On every boot there is red warning saying contact hp that system setup is incomplete. I wonder if that is uefi debugging enabled event.

Can Taipei contact hpe to do whatever needs to be done to put firmware into production mode without debugging enabled?

Possibly. Is this an Intel system? If so, I wonder whether it would fail the BootGuard configuration checks I have as well.

For the curious, this is how we do the BootGuard tests on Intel systems: https://github.com/canonical/secboot/blob/master/efi/preinstall/check_fw_protections_intel.go#L193