-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use coreboot vboot measured boot #562
Comments
merge
added a commit
to merge/heads
that referenced
this issue
May 20, 2019
Remove debug symbols and dynamic debug support from Linux. This reduces our resulting bzImage by 200K. This should help when size becomes even more limited, see linuxboot#562
merge
added a commit
to merge/heads
that referenced
this issue
May 20, 2019
Remove debug symbols and dynamic debug support from Linux. This reduces our resulting bzImage by 100K. This should help when size becomes even more limited, see linuxboot#562
More TODOs besides getting smaller and getting the X230 to work:
|
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the goal here is basically to close #41 . Currently we have https://github.com/osresearch/heads/blob/master/patches/coreboot-4.8.1/0000-measuredboot.patch that allows us to do measurements in initrd. We can still continue to use this on top of a recent release of coreboot and should do so, and update coreboot independently of this task!
Now since https://review.coreboot.org/c/coreboot/+/29547 and https://review.coreboot.org/q/topic:%22LENOVO_VBOOT%22+(status:open%20OR%20status:merged) coreboot allows to measure boot as part of the vboot scheme. Even if we won't use parts of vboot (keys in GBB), but only the measured-boot part, it would make sense to use a well-define upstream maintained solution.
A different FMAP (fmd file) is being used in that case:
vboot basically supports 3 different parition schemes (FMAP) to choose from, that defines what funcitonality will be available. "RW_A and RW_B" (which would enable updates) is out of scope for us due to size limitation. "RW_A only" would theoretically be possible, but would also impose at least some unnecessary size limitations and also, we would not need to have a pre-defined static "RO" seperate of "RW_A". Our root of trust will be just Heads itself with it's code up until the point where we will enable write-protection for the SPI flash. Basically, our flashrom update-scripts need to run before that. The paritioning scheme to use for use will most likely be "RO only" (even if it's no static read-only, but locks the flash at some point).
I only quickly tried to write an appropriate "vboot_ro.fmd" file (not yet merged upstream) for the x230. "RO only" still reduces the available CBFS size for coreboot+payload a little, in order to fit into the vboot mechanism and I ran into problems with building because our kernel+initrd are just a little to big:
Would this be enough? / Can this work?
So first, it seems like we need to reduce the size (of the x230 build). Mostl probably Linux.
And of course have a working fmd "ro" file (merged) and thus a working build. The tpm tools should still work, but what changes are needed in userspace for us to test this?
Please question everything I write here! I could be totally wrong about things and just want input from you if you know better. I hardly have had any time to look into this. Let's move forward and get rid of your patches.
The text was updated successfully, but these errors were encountered: