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...
).