[coreboot] [RFC] A more robust fallback system
hamo.by at gmail.com
Fri Nov 18 07:21:08 CET 2011
On Tue, Nov 15, 2011 at 7:07 PM, Noé Rubinstein
<nrubinstein at proformatique.com> wrote:
> 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
> 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
> Noé Rubinstein
> Avencall - XiVO IPBX Open Hardware
> 10 bis, rue Lucien VOILIN - 92800 Puteaux
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot