DTS IBG key verification enhancements #1717
Description
The problem you're addressing (if any)
The btg_key_validator script is a subboptimal and a temporary solution. And should be either integrated into DTS update workflow or cleaned up.
Describe the solution you'd like
A list of ideas for cleaning the script up:
- Make the final message (pass/fail) colored appropriately. https://github.com/Dasharo/dts-scripts/issues/135
- Instead of printing hardcoded messages about error, we should just print generic message that the key in the binary does not match expected hash. To be decided if we print additional info like filename/platform name (depending on use case described in point 3) and keyhash vs expected. https://github.com/Dasharo/dts-scripts/issues/134
- Make the script take 2 arguments: file path and expected hash. This would make the script usable to verify binaries offline before flashing. Of course if parameters are given, flashrom step should be omitted and key hash should be taken from second parameter. https://github.com/Dasharo/dts-scripts/issues/133
- NCM key hash is currently hardcoded and the only option to compare against. Reuse the DTS env variables o identify the platform and the key which the validator should check against. https://github.com/Dasharo/dts-scripts/issues/131
- Hash size is not automatically obtained. Grep for SHA length in the km-show output to use proper hashing algorithm to obtain the key hash. https://github.com/Dasharo/dts-scripts/issues/132
An example flow that could be integrated into DTS update workflow rep,lacing the script:
Note, that the flow is in highly draft state and is under internal review.
Where is the value to a user, and who might that user be?
Prevent users from bricking their platforms when updating firmware of a fused platform using a binary with a wrong IBG key.
Describe alternatives you've considered
Check the keys inside Dasharo firmware UEFI capsule.
Additional context
No response