On Tue, Nov 15, 2011 at 7:07 PM, Noé Rubinstein <[email protected]> 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: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
