Arthur Heymans has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36544 )
Change subject: security/vboot: Add rw_region_only support to vboot ......................................................................
Patch Set 4:
Patch Set 4:
(1 comment)
Patch Set 4:
Patch Set 4:
Patch Set 4:
(1 comment)
The idea behind this is that the update image needs to be created more often than the "factory image" containing the correct RO partition. So this should be as easy as possible so it would even be acceptable to have an update-image without the payload (as the RO part won't be used anyway). During development of the initial image we can simply start out by adding the small payload to both the RO and RW regions. So the number of manual actions required will be limited.
I think with chromeos new 'factory' images are always created regardless if the RO partition is already locked.
For my understanding why do you think it is easier to add the larger payload later? Now I can build the large payload with the coreboot tree and generate the image with the correct payload in one go. How would that work in your case?
I just think that handling payloads outside of the coreboot build system makes more sense when shipping images, especially if you want different things in RO vs RW.
Please note that this config is not intended for ChromeOS systems, the intention is to allow some deviation from that behavior for embedded systems. In our case, the system will be delivered with the default image loaded and the RO region of the flash device locked so this can't be altered. So after that, the content of the RO region is irrelevant as this will never be flashed.
Then you are probably better off having a way to generate just the RW regions instead of some weird hacks to limit what goes into the RO region?
What we want to achieve for the customer is an easy way to generate update images. After setup the customer will be able to run make menuconfig and make (or just generate a new payload is this is a bzImage or elf) and generate a new coreboot image.
This changes how a whole image is build, while you only care about the RW part. So why not just generate the RW part?
For some very specific customers we also have the requirement that the system should not boot at all if the verified boot check fails. In this case it doesn't make sense to waste space on a payload inside the RO region.
I know these are non standard situations but they still happen.
The best way seems to just build without payload and add it manually to the RW region or build a full image without payloads and update only the RW region later on to have a payload?
With image composing being done in makefile, maintainability quickly becomes a problem when trying to support different use cases. see CB:32687.