Thanks Julius. Yes I was referring to Coreboot versions. I have cited you in the link below so that the Heads community can build upon your feedback.
https://github.com/osresearch/heads/pull/709#issuecomment-707101935
Thanks Tim also for your help.
Kind regards, Thomas
On 10/12/20 9:14 PM, Julius Werner wrote:
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.
Well yeah, you can leave out the payload and that may be the biggest part for you. But technically you could also leave out romstage and ramstage in that situation, and the build system currently doesn't yet offer an option to allow that.
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.
Note that measured boot is independent from verified boot. The main point of verified boot is to allow keeping a part of the flash writable so it can be updated but is still cryptographically verified. If you don't care about that, you can just write-protect your whole flash and only enable CONFIG_TPM_MEASURED_BOOT. (Or, you know, not write-protect anything, but then both measured and verified boot become somewhat pointless because your trust anchor is not secure.)
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?
Are you talking about coreboot versions? Sorry, I don't follow the tags we cut super closely. The behavior I described has been pretty much unchanged since 2018, I think (so long before 4.12 or 4.11).
-
Thomas Clarke