Peter Stuge wrote:
I don't think any other part of flashrom bit twiddling does restore,
Yes. They all leave it open, as they do with the board enable and the chipset enable. This is a very high security risk.
Why do you think so?
If flashrom was able to unlock something, then another process with sufficient credentials will also be able to unlock that something.
If it knows how to do that, and if it intends to do that. If a process just goes berserk and for some reason writes the wrong sequence to some area in memory you might end up with an erased chip.
I don't buy in the argument that tossing the security to the OS or every single process just because the flash safety mechanism can somehow be circumvented is the way to go. You don't leave your root password open, just because someone could reboot the machine and come up with init=/bin/bash.
I'm not sure it actually matters anywhere?
Well, "It's broken everywhere else"...
Yes, if not locking == broken, but I'm not sure about that.
In my opinion, changing the system state is, though.
I seem to recall that there was discussion about restoring the board enable/chipset enable signals too. Someone mentioned that it wasn't always possible or safe to restore signals. I am not sure what the technical motivation for that was.
This is an urban legend. I restored the system state in my initial flash tool attempt /dev/bios on many chipsets. Sure. It takes quite some understanding about what IO areas you write to. But sure setting the system back to the state it was in before can not be more "unsafe" than leaving it in some "undefined" state (And the state is undefined for the rest of the system, that did not know we are running flashrom)
Stefan