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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
