Measuring GPU device firmware

[Rot127]

Is your feature request related to a problem? Please describe.

I was thinking about buying a new laptop with a GPU and use it with Qubes.
But in the Dasharo/dasharo-issues#1087 @marmarek is rightfully concerned that a VM which has control over the GPU could flash the firmware of it.

I was wondering if it would be possible to authenticate the GPU ROM/flash content hash as well.

I assume reading the GPU flash requires a proprietary Nvidia binary. But it could be authenticated as well before it is run.

Describe the solution you'd like

• Add Nvidia flash reader as blob
• On boot:
  • authenticate flash reader
  • read and hash GPU ROM/flash content
  • authenticate hash with TPM
• On failure inform the user about it.

Describe alternatives you've considered

• Measuring the OptionROM (vendor provided driver on the PCI device for UEFI (intro: https://blog.davidv.dev/posts/pcie-option-rom/ and EFI_DEFERRED_IMAGE_LOAD_PROTOCOL docs: https://uefi.org/specs/UEFI/2.10/36_User_Identification.html?highlight=efi_deferred_image_load_protocol#deferred-execution)): Measuring GPU device firmware #2004 (comment)
• Trust the authentication the GPU does before it writes it's flash.
• Yolo into it and ignore the security hole.

Additional context

Dasharo/dasharo-issues#1087

[Rot127]

On Reddit someone documented how to flash the GPU BIOS:
It doesn't look good, because apparently people use a leaked Nvidia tool called nvflash.
We couldn't use these of course.

But since we just need reading of the GPU flash, and we only need it for one or two cards, could we maybe reverse it and implement our own tool (nvflash bins are stripped though)?

[marmarek]

For the purpose of boot integrity, it might be enough to measure just OptionROM (for which standard access method exists) before executing it. This assumes that if OptionROM wants to execute any other code (I'm not sure if that's even the case), it will verify its hash/signature. Not perfect (we've seen a lot of cases when vendor missed signature check...), but should cover majority of cases in practice.

Dasharo/dasharo-issues#1087 (comment) is another idea how to verify it

[Rot127]

it might be enough to measure just OptionROM

Just caught up with the suggestions in Dasharo/dasharo-issues#1087
Also read up about UEFI and OptionROM (it's new to me), but it seems like my casual idea of a nvflash clone wouldn't work anyways. Since the tool relies on reading /dev/mem and I assume the OptionROM code will be responsible to map the GPU flash/ROM to a physical address range?

In any case, OptionROM seems indeed the way forward then.
I assume secure boot is measuring it as well? Or does it check also something else?

OptionROM verification would be required anyways. And extending Heads with it would be pretty nice.

[tlaurion]

It is realms of chainloading seabios+heads since coreboot always tried to get away of dealing with this.

Also see #1792 #1820 #1752 #718

cc @Rot127 @marmarek

[Rot127]

Some quick links:

SeaBIOS option rom handling: https://github.com/coreboot/seabios/blob/master/src/optionroms.c
and as it looks like it has a validator function we could patch: https://github.com/coreboot/seabios/blob/0026c353eb4e220af29750fcf000d48faf8d4ab3/src/optionroms.c#L70-L87

SeaBIOS TPM driver: https://github.com/coreboot/seabios/blame/master/src/hw/tpm_drivers.h

Also, how would an OptionROM update work btw?
Assuming a GPU firmware update patches it, SeaBIOS can reject to load it but has to pass the new hash somehow to Heads, which then updates the TPM if the user allows it? Then reboot so SeaBIOS can execute the OptionROM again?