[flashrom] [PATCH] Warn of one-time programmable (OTP) memory

[Carl-Daniel Hailfinger]

Hi Stefan,

I have waited very long to comment on this patch, but I simply don't
have a good answer for it.
I do think that OTP/security memory is outside the scope of flashrom
because it behaves totally different (and testing could easily kill a
dozen chips during inital implementation, and a few chips each time
someone wants to retest). Now if something is outside the scope of
flashrom, should flashrom care at all? Some flash chips have GPI pins
(GPIO without output) and those are readable with commands very similar
to those used by flashrom. Should we tell the user about that feature as
well? We had such requests in the past, and I was not really happy about
them.


Am 14.08.2011 05:36 schrieb Stefan Tauner:
> Some flash chips contain OTP memory that we cannot read or write (yet). This
> prohibits us from cloning them, hence warn the user if we detect it. Not all
> variations of the tagged chips contain OTP memory. They are often only
> enabled on request or have there own ordering numbers. There is usually no
> way to distinguish them afaict.

Well, it's worse than that. I've seen datasheets for flash chips with
the following features:
- OTP memory, fully readable, fully writable once in one block (no
partial writes)
- OTP memory, fully readable, fully writable once per byte (partial
writes work just fine)
- OTP memory, fully readable, fully writable once per 2^n-byte block
- OTP memory, fully readable, only half of it writable, the other half
is programmed at the factory
- OTP memory, fully readable, completely pre-written at the factory (so
it's rather ROM than OTP)
- Hidden OTP memory which can only be read if you know the correct
security ID which is part of the OTP
- (The complete flash chip behaves like OTP (well, like ROM) once a
specific write-once status register is set)... not relevant here

And then you have the problem that multiple chip generations often share
the same device ID, so probing can't differentiate between a chip with
OTP and one without unless you're extremely lucky. Do we want
FEATURE_OTP and FEATURE_MAYBE_OTP?

Do we warn if a chip has a readonly serial number? That means the chip
can't be cloned. People who care about OTP for clonability reasons
probably care about other readonly contents as well. OTOH, other people
who don't use the OTP at all (for them, OTP is just an accidental
feature of a cheap flash chip) don't want to be bothered by yet another
line of output from flashrom which has no relevancy for them.


> The manpage is extended to describe the backgrounds a bit. While i touched
> that section, i also reformatted it a bit and removed the reference to the trac
> bug reporting facility.
>
> This patch is based on the idea and code of Daniel Lenski.
> ---
> the reason i removed the trac reference is that it is not used, i have no (working)
> login and it does not really fits our work flow anyway. the only user that used it
> in my active flashrom time ranted about it. would anyone miss it?

To be honest, trac is something I never got along with. Even if I'm
logged in there is no way for me to read the email address of the person
who opened the bug, so communication is pretty difficult. I'm all for
checking all old trac tickets, closing what can be closed, and moving
all other tickets in some way or another to the mailing list. However,
we should mention that it's OK to report bugs via IRC as well as long as
the reporter mentions a way to contact hi/her (i.e. email address).

Removing the trac reference and adding the IRC reference should be a
separate patch, though, which is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

One comment about the man page formatting: This part of the patch may
conflict with the other man page formatting patch you sent. By the way,
do you know any good reference about man page formatting? I had trouble
finding out what .RE and .RS do.


> the new default verbosity output is:
> This chip may contain one-time programmable memory (see man page for details).
>
> the new dbg1/-V output is:
> This chip may contain one-time programmable memory.
> flashrom cannot read, and may never be able to write it. flashrom may not be
> able to completely clone the contents of this chip (see man page for details).
>
> there are certainly more chips with OTP memories out there. additions are
> welcome!
> i have only tagged chips with user modifiably OTP/security memories. there
> are some chips out there which have factory written IDs, but no OTP memory.
> a similar warning could/should be printed for those, but i did not want to
> abuse the OTP tag for this. also, there is nothing we can do, but read those IDs.
> duplicating chips using them is not possible, so a warning in the man page might
> suffice?
>
> since OTP memory (or any other data outside the linear address range of the
> "main" memory) can not be handled very well in flashrom right now, it is not
> clear how OTP memory access could be developed further. of course one could
> start to implement the basic methods needed to read them, but how they
> should be integrated then is not clear.
> one could start by adding an otp_print field to the struct flashchip and just
> dump the bytes on probing similar to the lock printing (not on default verbosity
> and possibly only if there are bytes different from 0x00 and 0xff).
>
> carl-daniel seems to be quite sceptical regarding handling OTP at all in flashrom.
> he stated "it does not really fit our device model at all", which is right, but could
> be changed.
> he also asked "should we really handle all features present in flash chips?"
> and the answer is probably "no", although i don't see a reason why we should
> not, if the effort is not too much and the architectural changes needed aren't
> obvious NOGOs.
> but OTP regions are somewhat special, they are not just *some* feature.

Indeed.


> one argument is the one stated in the message printed by this patch. flashrom
> is not able to clone chips that have some kind of OTP memory written right now.
> imo "cloning" a flash chip seems to be a valid use case for a tool like flashrom as
> long as it is feasible (which is not for chips with unique, preconfigured IDs).
>
> the other more theoretical argument i have is: OTP memory is just some
> memory in the flash chip. it may need other access patterns, but it is not much
> different from other write protected memories apart from that.
> some chips implement it in a way that it is even possible to erase the OTP
> regions. those regions are just normal flash and are made unwriteable by fuses
> in a register or another addressable byte.
>
> Signed-off-by: Daniel Lenski <dlenski at gmail.com>
> Signed-off-by: Stefan Tauner <stefan.tauner at student.tuwien.ac.at>

Stefan: I don't want to veto this patch, and although I think that OTP
handling is not really a flashrom feature, I think that this
implementation satisfies the quality criteria for merging, so the patch is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/