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,
--
Michał Żygowski
Firmware Engineer
GPG: 6B5BA214D21FCEB2
https://3mdeb.com | @3mdeb_com
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
