[coreboot] flashrom: Support Pm49FL004/2 Block Locking Registers

Stefan Reinauer stepan at coresystems.de
Sat May 17 15:43:10 CEST 2008


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





More information about the coreboot mailing list