search

linuxboot / fiano

Go-based tools for modifying UEFI firmware
BSD 3-Clause "New" or "Revised" License
303 stars 49 forks source link

Workaround for an error: conflicting erase polarities, was 0x00, requested 0xFF #329

Open xaionaro opened 3 years ago

xaionaro commented 3 years ago

Hello!

I'm parsing firmwares to analyze corruptions. But there is a non-corrupted firmware (provided by our ODM), which is non-parsible by fiano, it returns an error:

conflicting erase polarities, was 0x00, requested 0xFF

Also I read multiple firmwares in a concurrent way (within concurrent routines), so switching the Attributes.ErasePolarity value is not a very good option. So I'm wondering: is it possible to workaround this problem?

GanShun commented 3 years ago

I vaguely remember that there's supposed to be some header which tells you what the polarity is, I think it might be in the firmware volume header. We should read that and automatically apply it, however it raises the question of what happens if we see conflicting volumes. The erase polarity should really be stored in a global header of some sort instead of the fvheader I think.

xaionaro commented 3 years ago

OK, thanks for the response.

Since I do not modify firmwares: is it safe to just ignore this error (just patch the local copy of fiano to avoid this check)?

GanShun commented 3 years ago

yes it should be safe. If it becomes a pain, we can work that into some kind of warning that doesn't terminate the parsing

trynity commented 2 years ago

yes it should be safe. If it becomes a pain, we can work that into some kind of warning that doesn't terminate the parsing

It has now become a bit of a pain, since we're wanting to try and get back to vanilla upstream rather than relying on our fork. Would it be possible to see about having a warning rather than a hard error?

trynity commented 2 years ago

@GanShun Following up on this again, should we just make a PR for what we have to bypass this, and continue work there? It'd be grand to be back on upstream and not have to deal with forks

rihter007 commented 2 years ago

Maybe it is time to add per-call settings instead of global?

GanShun commented 2 years ago

I'll look into making it a per call setting next week!

xaionaro commented 1 year ago

Do not want to annoy, but I'm curious if I can help to move forward with this problem somehow :)

xaionaro commented 1 year ago

I've just created a PR out of the code I patched our internal fork/derivative with in 2021. Feel free to reject it, just sharing :)