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