Hello coreboot community,
Google's vboot has been with us (coreboot) for many years already, probably mainly on Chromebook devices. In 3mdeb we have been using it with coreboot for a couple years as well.
From a user and developer point of view, vboot is a great library that hardens the firmware with cryptographic verification of the executable code and provides a redundant A/B + recovery layout scheme. However, it comes with a couple of limitations we have observed throughout the years:
1. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the vboot submodule revisions get updated too. Occasionally it may lead to backwards incompatibility between recovery and A/B parts (assuming that only A/B is updated and recovery remain write protected) . 2. Sometimes when the coreboot-based firmware is updated on a device after a longer period of time, the car.ld (or any program layout shared across multiple stages in both recovery and A/B like bootblock and romstage/postcar) gets updated too. Almost every time it leads to backwards incompatibility and a brick.
There may be other cases as well, which need special handling and testing, because it may not be safe to flash an update on a device. One solution may be to freeze the codebase on given revisions and avoid updating them, but that's not what we typically want. I came up with the following idea:
Leverage the top-swap mechanism to provide two bootblocks with verstages (assuming verstage starts in bootblock and no separate verstage):
- Top Swap RO - used for booting recovery only (built with vboot submodule from coreboot revision X) - Top Swap RW - used for booting RW A/B only (built with vboot submodule from coreboot revision Y)
Example (simplified) flashmap layout could look like this:
RW_B (optional RW_A WP_RO { FMAP GBB COREBOOT TOP_SWAP_RO } TOP_SWAP_RW
- TOP_SWAP_RW would be the default one placed right under top of 4G. - Whenever vb2api_fail is called, coreboot would have to switch the top swap to TOP_SWAP_RO. - TOP_SWAP_RW is updatable so should be unlocked, like RW_A/B. But verstage should be protected
coreboot has some code/logic for building an image with top swaps, so I think it is doable.
Unsolved problems or questions:
1. Having two distinct vboot builds does not prevent from backwards incompatibility in vboot NV storage layout. Does the layout of vbnv even change? For the past 10 years the offsets have not changed (only one new flag and one flag name modification). So we can assume it is not a problem. 2. There might be other incompatibilities I am unaware of. Different recovery reasons codes shouldn't be a problem generally. 3. Chromebooks usually write-protect WP_RO region. In the scheme above, the TOP_SWAP_RW would be unprotected. Do Chromebooks still use WP screws and SPI chip provided protections?
- In 3mdeb we use the chipset PRx registers to protect the recovery part of the firmware. It gives a possibility of 4K granular protection of the SPI firmware. Multiple PRx registers could be used here: 1 - protect WP_RO, 2 - protect TOP_SWAP_RW. On updates lift the protection on second PR only - Ideally the top swaps could be protected/verified by solutions like Boot Guard (AFAIK boot Guard can support top swap, haven't researched yet how it works in practice). Then write protection of TOP_SWAP_RW would not be a concern.
4. Changes in the flashmap layout. This is rather out of scope, as any change in flashmap layout would imply updating whole BIOS region typically. So I would exclude this for now.
The solution is Intel-only, not aware of top-swaps on AMD, except PSP/ASP 16MB flash page limitations and top-swap like behavior. Also AMD is a whole different story, because bootblock is integrated into PSP/ASP directory, which has its own A/B (and two level) mechanism + psp_verstage... So leaving that aside for now.
Looking for your insights, comments, suggestions, any problems you see with the approach (haven't started any development yet) etc. Appreciated in advance.
Best regards,