[flashrom] [PATCH] ichspi.c: warn user when a protected region is detected

[Stefan Tauner]

On Sun, 27 Nov 2011 11:48:51 -0800
David Hendricks <david.hendricks at gmail.com> wrote:

> On Sat, Nov 26, 2011 at 3:35 PM, Stefan Tauner <
> stefan.tauner at student.tuwien.ac.at> wrote:
> 
> > This includes the notorious read-only flash descriptors and locked ME
> > regions.
> > ---
> > non-verbose sample output from my laptop:
> > […]
> > Found chipset "Intel QS57". Enabling flash write... WARNING: SPI
> > Configuration Lockdown activated.
> > WARNING: Flash Descriptor region is not fully accessible and flashrom can
> > not deal with this correctly yet. Intel does not provide us the necessary
> > documention to support this.
> 
> 
> To be fair, I think Intel documents it fine.

That depends on what 'it' is. The limitations and the influence of
FDOPSS on that limitation are well defined in public documentation. But
the unlocking process is not documented at all publicly. We know from
different leaked documents and also from the fact that vendor tools
exist, that unlocking can be done by software only and without touching
the FDOPSS pin by sending the "HMRFPO Enable" command via HECI/MEI to
the ME. The details are documented in the BIOS writer guide(s) (which
are "restricted secret" level(?))

> I think what we've got to do
> is checking the flash descriptor override pin strap status (FDOPSS). If it
> is cleared then we can ignore the descriptor, otherwise if it is set then
> we need to avoid locked regions.

I would not call it 'ignoring'. We should be aware, that the limitation
do not apply (we do print a message to the user already in that case),
but we could and should use the regions where it makes sense
(e.g. automatic creation of layout (file)s.

> It's really just a pain in the ass and, as you pointed out, may leave the
> BIOS/ME firmware blobs in an inconsistent or incompatible state. So the
> onus is on the user to ensure a safe upgrade path if only part of the ROM
> can be updated. It's probably worth displaying a warning and requiring
> "--force" or something in that scenario.

As a first step yes. IIRC i have sent a patch that does that when active
PR protections are found(?), but i think it is not in/reviewed yet. I
agree, we should set write_allowed = 0 (or whatever it was) and
rephrase the warning to include that.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner