Looked further into the "bunch of motherboard vendors fucked up Secure Boot" issue.

This is an issue in AMIBIOS.

The following is purely from static analysis, I haven't checked in practise yet (if anyone wants to check, I can do something to check given enough time I guess)

AMIBIOS stores the secure boot validation policy in {7B59104A-C00D-4158-87FF-F04D6396A915}!SecureBootSetup variable.

It can be overwritten in boot services, but you need to set {E770BB69-BCB4-4D04-9E97-23FF9456FEAC}!SystemAccess (EFI_VARIABLE_BOOTSERVICE_ACCESS, volatile) to 0 first. This is because a certain function checks this, and I don't see anything that blocks anyone post-DXE but still in boot services just setting it themselves.

The SecureBootSetup variable should be 8 bytes long, and offset 4 contains the setting for Option ROM, offset 5 for removable media and offset 6 for fixed media.

The possible values are: enum { AlwaysExecute = 0, AlwaysDeny, AllowExecute, DeferExecute, DenyExecute, QueryUser }

As for what alwaysexecute actually does: it causes the function that checks a PE signature to return success before doing anything. A side effect of this is nothing gets measured in PCR7, at all.

As far as I am aware, BitLocker does check for this and will refuse to use secure boot for integrity validation in this case. Of course, a supply chain attack could just plant a bootkit and measure something itself...

#sbctl #SecureBoot #security #AMIBIOS #AMI #infosec #MSI #UEFI