[coreboot] [RFC] A more robust fallback system

[Hamo]

On Tue, Nov 15, 2011 at 7:07 PM, Noé Rubinstein
<nrubinstein at proformatique.com> wrote:
> 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.
>
This method looks like the same as what I have done when dealing with
different ARM boot rom address mapping.
The different is that I also put this address into the master header so that
other component or walk_cbfs can get it there.

> 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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>