Re: [flashrom] GSoC-2014 Flashrom project "Locking and unlocking of access protections of flash chips"

[David Hendricks]

On Wed, Mar 19, 2014 at 5:58 AM, Allen Yan  wrote:
> Hi, David,
>    I was reading flashrom code base following the internal programmer
> way. I also read mail
> "http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html"
> and checked the Ibex peak datasheet about ME firmware. Here are some
> questions:
> about "Locking and unlocking of access protections of flash chips"
>  1 which mechanism locks the flash?a software  way or a hardware way
> by the programmer. As in the Atmel AT25DL161, the protection ways are
> "hardware protection, using WP pin", "Sector lockdown with permanent
> freeze option", "individual sector protection with global
> protect/unprotect feature".

All of the above :-)

You will need to determine:
- Which write-protection scheme is in place? Is it intended to prevent
erroneous software from writing to the flash, or is it intended to prevent
any re-writing of the flash?
- Can it be disabled / worked around so that content can be updated?
- How to restore the settings when you are finished.
> 2 Does this problem concerns the ME firmware issue.

Yes.
> 3 How to do the test? Is the test at specific mainboard and flash chip
> enough?

IIRC Flashrom already tests for motherboards which are known to require a
workaround, for example if a GPIO must be inverted in order to de-assert
/WP. board_enable.c has many of these tests. It also knows about block
protect bits in SPI ROMs.

I think the main issue with modern systems (Intel in particular) is the
management engine.
> 4 How to value the work at last as stefan mentioned in the suggestion?
>
> Actually, a little frustrating after I saw stefanct's mail.

It's very valuable :-) I put some effort into this functionality for
ChromeOS, since handling write-protection is a requirement for Chromebooks.
Here are some examples:
Skip regions locked via flash descriptor for Intel platforms:
https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/1ed1d35d...
writeprotect.c, which contains block protect mapping for several flash
chips:
https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/w...

Unfortunately we never reached a consensus regarding how to port this code
to upstream. It would be nice if somebody like you can help to re-factor
this code so that it can be accepted upstream.
> On 3/18/14, Stefan Tauner  wrote:
> > On Mon, 17 Mar 2014 09:56:43 +0800
> > 严进一  wrote:
> > > Hi,
> > > I am Jinyi Yan , a second year PhD candidate from Shanghai Institute of
> > > Micro-system and Information Technology, Chinese Academy of Sciences. I
> > > used to be a mainboard BIOS engineer in ASUS Technology Suzhou Co., Ltd
> > > for about two years (2007.7~2009.2). My major now is optoelectronics.
>
> But
> > > I have a lot of fun while programming, in my heart the working
>
> experience
> > > of being a BIOS engineer is still very exciting.
> > > I think GsoC is a nice platform for me to participate the open source
> > > community. When I search the GsoC projects and organizations, the
>
> coreboot
> > > and flashrom projects are definitely the right choices for me. I have a
> > > spare ASUS P5KPL PC at my hand, but the chipset is not in the support
>
> list
> > > of coreboot project. So I consider the flashrom project is the better
> > > choice. I also have a home-made flash programmer based on uspasp.
> > > I'd like to choose “Locking and unlocking of access protections of flash
> > > chips” for GSoC 2014.
> > > Now I'm not very familiar with the program structure of flashrom, so I
> > > expect your guidence and hope to contribute for flashrom and coreboot
>
> even
> > > if my application is not accpeted.
> > > Thanks! Look forward to your kind advice!
> >
> > Hello Jinyi,
> >
> > thanks for your interest in flashrom. I have been the most active
> > flashrom developer in the last years and would probably be responsible
> > to integrate your work and answer questions if you get stuck. I agree
> > that the coreboot-related projects are probably the best choice for you
> > (there are not many low-level projects participating sadly... that's
> > how I ended up here too ;). I also have to admit that the P5KPL is
> > probably not very helpful AFAICT. But I don't think that this is a show
> > stopper regarding coreboot (or seabios) projects and that your skills
> > and insights obtained at ASUS regarding x86 might be more useful in a
> > non-flashrom project. Also, the project you chose requires to
> > understand two code bases ("ours" and that maintained by google/
> > chromiumos ppl) and interact with two communities and persuade at least
> > one of them that your solution is sound and profitable. On the other
> > hand, I am biased because I will apply for a flashrom GSoC project
> > myself probably. ;)
> > The code bases have a very similar core so that should not be a big
> > issue at all. Producing something that will be praised by everyone on
> > the other hand is really hard. The vanilla flashrom community is
> > traditionally very (very) picky regarding changes, especially user
> > interface changes. This is also the reason why there is a chromiumos
> > fork of flashrom...
> >
> > I have talked to David (dhendrix) and he is willing to mentor you this
> > year. If you want to pursue this project (and the patch you sent seems
> > to indicate that ;) I suggest you talk to him directly about details
> > of the assignment (here or on IRC).
> >
> > Adding new flash chips as you have done is a very good first step to
> > get to know flashrom a bit better. The fun begins with the awkward
> > models though :)
> > I suggest you test flashrom on any hardware available to you (including
> > network cards for example)... there is always room for improvement and
> > learning a foreign code base is always easier when on has a specific
> > goal to reach.
> > --
> > Kind regards/Mit freundlichen Grüßen, Stefan Tauner
> >
> > flashrom mailing list
> > [e-mail]
> > http://www.flashrom.org/mailman/listinfo/flashrom