grawity/tpm_futurepcr

Error resulting from unexpected boot event

jocado opened this issue · 3 comments

Hi,

If I run the following command:

tpm_futurepcr -H sha256 -L 0,4,7 --allow-unexpected-bsa -v

I get an unexpected bsa that results in an error:

Path vector:
  * MediaDevice          FilePath             \EFI\UBUNTU\grubx64.efi
  * End                  255                  b''
unsupported operand type(s) for +: 'NoneType' and 'str'
warning: couldn't map EfiBootServicesApplication event to a Linux path
--> after this event, PCR 4 contains value 5e6f520d840a9e12c8f19faca18e33617494030bae657e0d0fb42b18dc617b14
--> after reboot, PCR 4 will contain value 5e6f520d840a9e12c8f19faca18e33617494030bae657e0d0fb42b18dc617b14

~~~8<~~~
fatal errors occured

The problem seems to be here: https://github.com/grawity/tpm_futurepcr/blob/master/tpm_futurepcr/device_path.py#L79-L81

In the case of MediaDevicePathSubtype.FilePath then dir_path always remains None and can't be concatenated with the file_path str.

In this particular case, the dir path should be /boot/efi, as the full path would be /boot/efi/EFI/UBUNTU/grubx64.efi

If I hack that value in, it basically works [ although it's still an unexpected bsa of course ]

I would submit a PR, but I'm not sure what the sane default should be in this case. As I say, the actual path is not there at all, so how should it be determined ? You can check it in fstab, but don't know if that's something you would advocate.

Cheers,
Just

Might this be already fixed in a firmware update?

I guess I could make it look for /efi or /boot/efi as a fallback if the device is somehow unknown.

But it shouldn't be reported as an unexpected event if it can be mapped to a Unix path.

Hi. Apologies for the delay in responding.

I did try a firmware update, but it didn't seem to make much difference unfortunately.
Not sure if it's just bad firmware of what really, but it seems I'm probably not going to be able to use this for leveraging pcr 4 on these devices [ Intel NUC ] as is.

Do you think trying /efi and /boot/efi as fallback is a sane approach ? I could submit a PR it's not objectionable.

That should work, as long as you also check whether the path is a mountpoint (I'd just invoke mountpoint -q or findmnt via subprocess...) – that would also allow detecting /boot when it itself is the ESP with /boot/efi as just a subdirectory.

The earlier #7 might also help here, as it should allow you to remap individual paths if they're detected incorrectly for whatever reason (e.g. remapping /EFI/UBUNTU... to /boot/efi/EFI/UBUNTU...).