Hi Julius,

Actually the behaviour you described in the 'third combination' I've been able to achieve by having a tiny RO_SECTION and a large RW_A and excluding the payload from being written to the RO_SECTION. It just felt a bit like cheating but I may invest more time into it to see if its usable. Ultimately the goal (at this time) is to have measured boot by expanding hashs into PCR's which can be verified by the end user using TOTP.

Another question if I may, does the behaviour you described apply to 4.12 also? I ask as there are a lot of boards that have a vboot-ro.fmd. Would these also fail for the reasons you have described or is there better support for this in 4.12 opposed to 4.11?

Regards,

Thomas-------- Original Message --------
On 9 Oct 2020, 10:53 pm, Julius Werner < jwerner@chromium.org> wrote:

Hi Thomas,

I think the combination you're trying to build just doesn't work and
isn't really supposed to work, honestly. Unfortunately, the current
state of those Kconfig options was implemented by contributors who
weren't the primary vboot developers and pushed through somewhat
hastily without really working out what option combinations make
sense. There have been a couple of discussions about how this should
be changed for the better (although I can't really find them anymore
right now, some random Gerrit CLs two years ago) but I think basically
it's just been stuck like this for a while with nobody having the time
or pressure to clean things up.

vboot was originally designed to be used with VBOOT_SLOTS_RW_AB,
that's the most supported and most tested mode. I guess running it
with VBOOT_SLOTS_RW_A should also work, although some of the internal
logic is going to get a bit confused about the missing slot B, but
eventually it should end up falling into the correct high-level
behavior (that when slot A is broken, it falls into recovery mode).
But building vboot without any RW slots makes no sense: the whole
point of vboot is to verify RW slots. Without RW slots you don't need
vboot. If your whole flash is write-protected (and therefore trusted)
anyway, there's no reason to cryptographically verify any of it on
boot.

The third combination that would actually make sense is to have one RW
slot but to have no recovery mode fallback in the RO_SECTION. That
would be what you want for the tiniest possible flash usage, basically
(accepting the risk that if the RW_A section becomes corrupted your
device would just be a brick). But that combination is currently not
implemented.