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.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
