[prev in list] [next in list] [prev in thread] [next in thread]
List: flashrom
Subject: Re: [flashrom] [RFC + PATCH] lock command for flashrom
From: David Hendricks <dhendrix () google ! com>
Date: 2011-01-28 23:00:50
Message-ID: AANLkTimNpBFVxEvG4er46H4kvqHHsbHxaeq__nFV_Pz- () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause
<mathias.krause@secunet.com>wrote:
> Hi,
>
> flashrom currently tries to unlock the chip before each read/write/erase
> command. To prevent further modifications of the chip content, e.g. for
> security reasons, it would be helpful if flashrom would also be capable
> of the opposite operation. I talked with Carl-Daniel a little about it
> and he mentioned problems like having to implement features like partial
> locks, chips that cannot be unlocked after being locked, etc. To support
> those features and handle the problematic chips something more than this
> little patch can do must be implemented. But for now it would be nice to
> have *something*. See it as a starting point to solve the much bigger
> problem.
>
Yep, it certainly gets hairy.
On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause <mathias.krause@secunet.com>
wrote:
> This patch adds a function pointer to struct flashchip and a command
> line option to trigger this function to enable full flash chip write
> protection. It's currently only implemented for the Atmel AT26DF081A
> since this is the chip I'm currently working with and which I can test
> easily.
>
For what it's worth, we've been doing something similar in the Chromium OS
branch (http://git.chromium.org/gitweb/?p=flashrom.git;a=tree). Apologies if
it seems a bit sloppy at the moment, we've had to wedge in a lot stuff to
solve immediate concerns.
We also added a member to the flashchip structure (.wp), but in our case it
is a pointer to a "writeprotect" structure which contains a bunch of
function pointers. We felt this was necessary since write protection varies
greatly between chips and we want fine-grained control.
In our model, the user specifies the byte range (offset and length) and
enables write protection in two steps. For example: "flashrom --wp-range
0x200000 0x200000 --wp-enable".
Most of the ugly stuff in our code is contained within writeprotect.c. So if
you want to give it a try it should integrate into your tree pretty easily.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
[Attachment #5 (text/html)]
<div class="gmail_quote">On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause <span \
dir="ltr"><<a href="mailto:mathias.krause@secunet.com" \
target="_blank">mathias.krause@secunet.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
Hi,<br>
<br>
flashrom currently tries to unlock the chip before each read/write/erase<br>
command. To prevent further modifications of the chip content, e.g. for<br>
security reasons, it would be helpful if flashrom would also be capable<br>
of the opposite operation. I talked with Carl-Daniel a little about it<br>
and he mentioned problems like having to implement features like partial<br>
locks, chips that cannot be unlocked after being locked, etc. To support<br>
those features and handle the problematic chips something more than this<br>
little patch can do must be implemented. But for now it would be nice to<br>
have *something*. See it as a starting point to solve the much bigger<br>
problem.<br></blockquote><div><br></div><div>Yep, it certainly gets \
hairy.</div><div><br></div><div>On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause \
<span dir="ltr"><<a href="mailto:mathias.krause@secunet.com" \
target="_blank">mathias.krause@secunet.com</a>></span> wrote: </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">This patch adds a function pointer to struct flashchip and a \
command<br> line option to trigger this function to enable full flash chip write<br>
protection. It's currently only implemented for the Atmel AT26DF081A<br>
since this is the chip I'm currently working with and which I can test<br>
easily.<br></blockquote></div><br><div>For what it's worth, we've been doing \
something similar in the Chromium OS branch (<a \
href="http://git.chromium.org/gitweb/?p=flashrom.git;a=tree" \
target="_blank">http://git.chromium.org/gitweb/?p=flashrom.git;a=tree</a>). Apologies \
if it seems a bit sloppy at the moment, we've had to wedge in a lot stuff to \
solve immediate concerns.</div>
<div><br></div><div>We also added a member to the flashchip structure (.wp), but in \
our case it is a pointer to a "writeprotect" structure which contains a \
bunch of function pointers. We felt this was necessary since write protection varies \
greatly between chips and we want fine-grained control.</div>
<div><br></div><div>In our model, the user specifies the byte range (offset and \
length) and enables write protection in two steps. For example: "flashrom \
--wp-range 0x200000 0x200000 --wp-enable".</div><div><br>
</div><div>Most of the ugly stuff in our code is contained within writeprotect.c. So \
if you want to give it a try it should integrate into your tree pretty easily.</div> \
<div><br></div><div>-- <br>David Hendricks (dhendrix)<br>Systems Software Engineer, \
Google Inc.<br> </div>
_______________________________________________
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic