Re: [RFC] Towards a more complete redundancy of firmware with vboot

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_g453AvdNE

> 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,
>

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]