Hi Michał,
we have had a discussion about this last fall in the coreboot leadership meeting on 2024-08-21 [1]. That time Matt brought it up. And your mentioned points where named back then, too. It was a intense discussion and several approaches were discussed together with their ups and downs. Nevertheless, the TOP_SWAP solution was not discussed to my memory and may indeed be helpful in this regard (though it might not be able to solve all known issues).
My proposal would be to bring this to the coreboot meeting again, showing that others (3mdeb) has the same issues. I think there is added value for the project if we could find a solution to this issue which fits all requirements from different parties.
Regards Werner
[1]: https://docs.google.com/document/d/1spx5B45u2IymaQitE-Thbqx4e4ykTok6a_g453Av...
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:
- 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:
- 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.
- 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,