Change ROM hash calculation to trust FMAP

Change ROM hash calculation to trust FMAP

Allowing the FMAP to override our default layout may be an exploit here, because
vendor can provide fake (non-used) GBB/BSTUB in unused area.
However since the flash memory layout may change, we need to trust FMAP.

BUG=chrome-os-partner:920
TEST=none

Change-Id: Icabd2febb04930a024ef5800ee09e3436de724ab

[Randall Spangler, 2010-09-09 22:22:30]

LGTM

The actual BIOS could read its data from somewhere different than the FMAP even
without providing a dummy one.

Fortunately, we can test that.  If we update based on the FMAP we detect, and
BIOS reports the value we updated, then it's using the data pointed to by the
FMAP.

[Hung-Te, 2010-09-10 12:12:44]

Hey Randall, I just got some other idea.

What about putting the offsets and sizes of the RO regions into hash?
Once we found matching hash, we can confirm all the addresses are not faked.

(But that would cause all existing hashes to be expired. So I need your confirm
if we're going to do this)

[Randall, 2010-09-10 15:38:45]

Hi Hung-te,

On Fri, Sep 10, 2010 at 5:12 AM, <hungte@chromium.org> wrote:

> Hey Randall, I just got some other idea.
>
> What about putting the offsets and sizes of the RO regions into hash?
> Once we found matching hash, we can confirm all the addresses are not
> faked.
>

Can you just add the FMAP itself to the hashed RO data?  Since it's in RO,
that makes sense, and it includes the offsets and sizes.


> (But that would cause all existing hashes to be expired. So I need your
> confirm
> if we're going to do this)


How about storing a "read only hash version" along with the raw hash?  If
"read only hash version" field isn't present, that means version 1, which is
what you do now.  Then version=2 means the hash includes the FMAP.

- Randall


> http://codereview.chromium.org/3328013/show
>

[Hung-Te, 2010-09-13 04:04:59]

On 2010/09/10 15:38:45, Randall wrote:
> Can you just add the FMAP itself to the hashed RO data?
   That would also limit the RW parts.
   Anyway we can do this first.

> How about storing a "read only hash version" along with the 
> raw hash?
   I just realized that there's no any hash values in component
   database yet, so we can simply push this change into ToT.