You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a vendor firmware image that prepends signature and certificates to the actual IFD image. The image is not dumped from the flash chip, but is provided along with their firmware upgrade tool.
This doesn't seem to be part of any standard, I rather believe it's a custom behaviour from the vendor's upgrade tool. This is handled, for example, by UEFITool in FfsParser::parseGenericImage, which is called only if a regular IFD starting at 0 is not found.
Even if this is a non-standard customization, I think it's an interesting feature to have. I can make a PR to support this use case with a -generic flag that will scan the file until it finds a valid IFD. What do you think?
The text was updated successfully, but these errors were encountered:
the thing is we already support generic images without an IFD, for example edk2's OVMF. I suspect what happened however is that the signature caused our FV headers to be misaligned. How would you fix this if there was an image with no IFD but the certificates caused the FVH signatures to be out of alignment?
@GanShun , if the image has no IFD and it's misaligned, I guess that the parser would just fail at some point.
What I would do is:
add a flag to FindSignature to say "search anywhere, not just at offset 0 and offset 16";
add a CLI flag to call FindSignature appropriately.
Then if it's an image that does not start at 0 and is not wrapped in an IFD, well, the parser will fail anyway, and we would still support all the previous use cases. Am I missing something?
I'd much rather it be seamless. Maybe we should allow searching the biosregion for any FV signature even if it's misaligned. The worry is that we may end up having false identifications of firmware volumes.
I have a vendor firmware image that prepends signature and certificates to the actual IFD image. The image is not dumped from the flash chip, but is provided along with their firmware upgrade tool.
This doesn't seem to be part of any standard, I rather believe it's a custom behaviour from the vendor's upgrade tool. This is handled, for example, by UEFITool in FfsParser::parseGenericImage, which is called only if a regular IFD starting at 0 is not found.
Even if this is a non-standard customization, I think it's an interesting feature to have. I can make a PR to support this use case with a
-generic
flag that will scan the file until it finds a valid IFD. What do you think?The text was updated successfully, but these errors were encountered: