Re: [coreboot] flashrom and PM49FL004/2

[Nikolay Petukhov]

Hi.

Patch[] already old.
Try this patch.

2008/3/18, malatesh kamatad <[e-mail]>:
> Hi .....
>
> We are working on Coreboot we are trying to flash on the
> PM49fl004/SST49lf004B
>
> but the flashrom has problems with the write and erase operation.
>
> We have MSI Neo and MSI K9N Ultra mother boards with socketed bios.
>
> So we are following the procedure what you have given in the
> mailing list (patch) ,
>
> After  compiling we are getting the error as bellow
>
> [malatesh@turtle22 flashrom]$ make
>
> Checking for pciutils and zlib... found.
> gcc -o flashrom chipset_enable.o board_enable.o udelay.o jedec.o
> sst28sf040.o am29f040b.o mx29f002.o sst39sf020.o m29f400bt.o w49f002u.o
> 82802ab.o msys_doc.o pm49fl004.o sst49lf040.o sst49lfxxxc.o sst_fwhub.o
> layout.o cbtable.o flashchips.o flashrom.o sharplhf00l04.o w29ee011.o spi.o
> -lpci -lz -static
>  sst_fwhub.o: In function `probe_sst_fwhub':
> sst_fwhub.c:(.text+0x21a): undefined reference to `probe_49fl00x'
> flashchips.o:(.data+0x644): undefined reference to `probe_49fl00x'
> flashchips.o:(.data+0x648): undefined reference to `erase_49fl00x'
>  flashchips.o:(.data+0x64c): undefined reference to `write_49fl00x'
> flashchips.o:(.data+0x670): undefined reference to `probe_49fl00x'
> flashchips.o:(.data+0x674): undefined reference to `erase_49fl00x'
>  flashchips.o:(.data+0x678): undefined reference to `write_49fl00x'
> collect2: ld returned 1 exit status
> make: *** [flashrom] Error 1
>
> I think we have down a mistake in this step ,
>
> we are  unable to understand  the step i.e
>
> diff -Nru flashrom/flash.h flashrom-pm49fl00x/flash.h
>
> --- flashrom/flash.h 2008-02-07 03:07:58.000000000 +0500
>
> +++ flashrom-pm49fl00x/flash.h 2008-03-11 13:38:25.000000000
> +0500
>
> @@ -373,9 +373,9 @@
>                              please guide us.............
>
> with regards ,
>     Malatesh.

flashrom: Support Pm49FL004/2 Block Locking Registers

[Peter Stuge]

On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
> Patch[] already old.
> Try this patch.

Here's an updated version.


//Peter

flashrom: Support Pm49FL004/2 Block Locking Registers

[bari]

Peter Stuge wrote:
> On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
> > Patch[] already old.
> > Try this patch.
>
> Here's an updated version.
>
> //Peter

Acked-by: Bari Ari <[e-mail]>

flashrom: Support Pm49FL004/2 Block Locking Registers

[Peter Stuge]

On Fri, May 16, 2008 at 08:08:16PM -0500, bari wrote:
> Peter Stuge wrote:
> > On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
> > > Patch[] already old.
> > > Try this patch.
> >
> > Here's an updated version.
>
> Acked-by: Bari Ari <[e-mail]>

Thanks!! r3332


//Peter

flashrom: Support Pm49FL004/2 Block Locking Registers

[Stefan Reinauer]

Peter Stuge wrote:
> On Tue, Mar 18, 2008 at 09:57:16PM +0500, Nikolay Petukhov wrote:
> > Patch[] already old.
> > Try this patch.
>
> Here's an updated version.
>
> //Peter

Instead of locking the chip, should we put it back to the state it was 
before? Does this make sense?

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866

flashrom: Support Pm49FL004/2 Block Locking Registers

[Peter Stuge]

On Sat, May 17, 2008 at 03:12:05AM +0200, Stefan Reinauer wrote:
> Instead of locking the chip, should we put it back to the state it
> was before? Does this make sense?

Good question. Actually I don't see why it would matter at all, what
matters is to unlock in order to erase or write.

I don't think any other part of flashrom bit twiddling does restore,
I'm not sure it actually matters anywhere?

I guess our policy is to leave bits unlocked. I'll read up on the PMC
chips and send a patch to remove the locking if it doesn't seem to be
harmful.


//Peter

flashrom: Support Pm49FL004/2 Block Locking Registers

[Peter Stuge]

On Sat, May 17, 2008 at 03:22:24AM +0200, Peter Stuge wrote:
> I guess our policy is to leave bits unlocked. I'll read up on the PMC
> chips and send a patch to remove the locking if it doesn't seem to be
> harmful.

Patch attached, but I sort-of feel like reverting 3332 and instead
making two new patches, with this change included in one.

Maybe we should rethink it a little and introduce a chip unlock
function that can fail? (Unlocking can fail on the PMC chips and then
they will not be writable until after reset. This exists in the ICH
SPI master and some SPI chips too.)


//Peter

flashrom: Support Pm49FL004/2 Block Locking Registers

[Stefan Reinauer]

Peter Stuge wrote:
> On Sat, May 17, 2008 at 03:12:05AM +0200, Stefan Reinauer wrote:
> > Instead of locking the chip, should we put it back to the state it
> > was before? Does this make sense?
>
> Good question. Actually I don't see why it would matter at all, what
> matters is to unlock in order to erase or write.
>
> 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.
> I'm not sure it actually matters anywhere?

Well, "It's broken everywhere else"... I figured it matters to some
extend, as you put the locking back in place. If you were inspired by
the other chips, you would have let the protection open ;-)
> I guess our policy is to leave bits unlocked. 
> Not a policy. If we want a policy, it can not be anything but "We leave
> the same way as we came"

Stefan

flashrom: Support Pm49FL004/2 Block Locking Registers

[Peter Stuge]

On Sat, May 17, 2008 at 01:51:32PM +0200, Stefan Reinauer wrote:
> 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.
> > 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.
> I figured it matters to some extend, as you put the locking back in
> place. If you were inspired by the other chips, you would have let
> the protection open ;-)

I didn't do much, this patch was written by Nikolay and Reinder, I
just reformatted it to HEAD and added the test flags.
> > I guess our policy is to leave bits unlocked.
>
> Not a policy. If we want a policy, it can not be anything but
> "We leave the same way as we came"

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. I guess this is what has left the
code in limbo..


//Peter

flashrom: Support Pm49FL004/2 Block Locking Registers

[Stefan Reinauer]

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

flashrom: Support Pm49FL004/2 Block Locking Registers

[Carl-Daniel Hailfinger]

On 17.05.2008 14:35, Peter Stuge wrote:
> On Sat, May 17, 2008 at 01:51:32PM +0200, Stefan Reinauer wrote:
> > 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.

Indeed.
> 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. I guess this is what has left the
> code in limbo..

Allow me to clarify. In the past, we restored the memory which was
written to during the flash chip probe sequence. That has proven to be
harmful, especially because the restored values sometimes did constitute
a valid command sequence for some flash chips. Since flash chips are
supposed to be ROM, a restore is only needed/possible if the flash chip
is shadowed by memory and in that case we can't probe for it anyway. So
any restore of the memory location contents touched during chip probe is
dangerous and pointless.

Restoring the state of the chipset and the lockbits of a chip is not
dangerous (unless a restore has unwanted side effects which would be
triggered by touching the register in the first place as well) and could
even be argued to constitute good style.

Regards,
Carl-Daniel