[coreboot] [RFC] A more robust fallback system

[Noé Rubinstein]

Hi,

This is an RFC.

I'm currently working towards providing a more secure fallback mechanism
to Coreboot.  I had pushed some preliminary changes to Gerrit some weeks
ago¹, and I've tried to take the reviews in account.  As the changes
touch some pretty critical parts of Coreboot, I'm sending this to the
mailing list for comments.  The patches are not ready yet, and the
changes that have been made to CBFStool and TINY_BOOTBLOCK et al.
recently will prolly make the rebasing work non-trivial.

On some chips, it is possible to block writing on some part of the ROM
when the system is running.  We (at my company) plan to use that to
prevent a careless user updating or modifying their BIOS to brick their
system, by putting a 'fallback' Coreboot in the high, write-blocked part
of the boot ROM, and using the fallback mechanism already implemented in
Coreboot in order to fallback in case the user-flashed firmware does not
work.

This requires an ability to specify that the components of a Coreboot
build have to be written in the high part of the ROM.  As cbfstool
already supports setting the precise address at which a file must be
mapped in memory, this could be implemented completely in the build
system.  However, this is non-trivial, so I really think it is better
for cbfstool to handle the calculations.

However, if the user writes in the low part of the ROM a Coreboot build
with the "fallback" CBFS prefix (which is the default), the fallback
mechanism won't work, as it will always boot on the first component
found with the right name.  That's why the fallback mechanism has to
search for the fallback image only in the high part of the RAM.  That
requires modification of walkcbfs_asm and of cbfslib to be able to find
a file after an offset.

In order to do this, we add a build option named OFFSET_IN_ROM which
defaults to 0x0 and enables putting Coreboot in the high part of the
ROM.  OFFSET_IN_ROM is used in the build system to call cbfstool
(including in order to call link the romstage properly), and is used in
Coreboot itself as an argument to the CBFS search functions.

Note that in order to write a component after an offset in cbfstool, the
whole beginning of the ROM has to be walked through in order not to
overwrite part of another file.  On the contrary, when looking for a
fallback component, the file headers before the fallback offset should
not be trusted (that's the whole point), so the beginning of the ROM
should be entirely skipped.

It is to be noted that this mechanism is still imperfect, as the CBFS
header is at the bottom of the ROM and holds info about file alignment
and offset.  In order to prevent problems, the implementation should use
conservative values instead of those written in the CBFS header.

I'm preparing a changeset implementing this mechanism.  I should post it
to gerrit soon if the reactions to this RFC are positive.

Later, we could implement a more robust solution would be storing
another CBFS header in the middle of the ROM; either completely
splitting the ROM in two or storing the second CBFS header as a CBFS
file.  In both cases, that would require much more effort to implement
than the current proposal.

Any idea/objection?

Thanks in advance.

¹: http://review.coreboot.org/284
   http://review.coreboot.org/285
   http://review.coreboot.org/286
-- 
Noé Rubinstein
Avencall - XiVO IPBX Open Hardware
10 bis, rue Lucien VOILIN - 92800 Puteaux