On Sat, Apr 01, 2017 at 07:43:40PM +0000, ron minnich wrote:
Annnnnnnd with the linux payload we're back to linuxbios :-)
It was a good idea in 1999, and it is still a good idea.
For a payload chooser and such I can offer two options:
- petitboot has a boot menu type thing
- u-root (u-root.tk) is going to have a boot menu type thing, as we've
been asked to do one.
Heads is coming along in usability and has a strong focus on securing the boot process through TPM measurement and using the flash security features. It fits the 4.9.20 Linux kernel + initrd into 4 MB, including all of the crypto, networking and other features. The eventual user kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via kexec for a slightly more secure, legacy free boot process.
More docs are online and pull requests are always appreciated:
On 04/01/2017 04:55 PM, Trammell Hudson wrote:
On Sat, Apr 01, 2017 at 07:43:40PM +0000, ron minnich wrote:
Annnnnnnd with the linux payload we're back to linuxbios :-)
It was a good idea in 1999, and it is still a good idea.
We *may* party like it's 1999 in 2017 then...
For a payload chooser and such I can offer two options:
- petitboot has a boot menu type thing
- u-root (u-root.tk) is going to have a boot menu type thing, as we've
been asked to do one.
Heads is coming along in usability and has a strong focus on securing the boot process through TPM measurement and using the flash security features.
Trammell, One of the three reasons we are including TPM in hardware is because of your great talk at 33c3 on Heads! But I failed to see that it offered "boot menu type thing"
It fits the 4.9.20 Linux kernel + initrd into 4 MB, including all of the crypto, networking and other features. The eventual user kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via kexec for a slightly more secure, legacy free boot process.
So this is referring more about "linux payload" than "boot menu type thing" correct?
More docs are online and pull requests are always appreciated:
What we are looking at is to include or develop a solution that accomplishes these goals: 1) allows us to skip most of vbios (but sounds like still needs the VBT) 2) deliver a payload that has a path toward securing the boot process (e.g. Heads) 3) deliver a payload that can still offer a user to install their own OS (thus allowing user-configuration and control)
Thanks for writing!
Todd.
On 02/04/2017, Todd Weaver todd@puri.sm wrote:
On 04/01/2017 04:55 PM, Trammell Hudson wrote:
On Sat, Apr 01, 2017 at 07:43:40PM +0000, ron minnich wrote:
For a payload chooser and such I can offer two options:
- petitboot has a boot menu type thing
- u-root (u-root.tk) is going to have a boot menu type thing, as we've
been asked to do one.
Heads is coming along in usability and has a strong focus on securing the boot process through TPM measurement and using the flash security features.
One of the three reasons we are including TPM in hardware is because of your great talk at 33c3 on Heads! But I failed to see that it offered "boot menu type thing"
It fits the 4.9.20 Linux kernel + initrd into 4 MB, including all of the crypto, networking and other features. The eventual user kernel (or Xen hypervisor and dom0 kernel) are GPG verified and invoked via kexec for a slightly more secure, legacy free boot process.
So this is referring more about "linux payload" than "boot menu type thing" correct? [...]
What we are looking at is to include or develop a solution that accomplishes these goals:
- allows us to skip most of vbios (but sounds like still needs the VBT)
- deliver a payload that has a path toward securing the boot process
(e.g. Heads) 3) deliver a payload that can still offer a user to install their own OS (thus allowing user-configuration and control)
Presumably petitboot, u-root, or another "boot menu type thing" could be included in Heads? This would seem to be the best outcome.*
Whether that would still fit into 4MB is another matter, but it seems worth a try. Even 8MB or 12MB would make it usable on some existing motherboards without the need to desolder anything.
I look forward to seeing what emerges from your (hopeful) collaboration!
* Formal verification of all this would be even better, but that's probably several years in the future :)
On Sun, Apr 02, 2017 at 09:18:10AM -0700, Todd Weaver wrote:
[...] One of the three reasons we are including TPM in hardware is because of your great talk at 33c3 on Heads!
I'm glad to hear that it inspired you to include it!
But I failed to see that it offered "boot menu type thing"
Currently there isn't any sort of boot selection menu; if the default doesn't work you can drop into a "recovery shell", which extends the PCRs to note that this has happened, and allows the user to manually mount devices, fixup signatures, run kexec, etc.
Adding a menuing system has been on the todo list for a while -- Zaolin started experimenting with plymouth, although it hasn't been integrated into the rest of the system.
[...] What we are looking at is to include or develop a solution that accomplishes these goals:
- allows us to skip most of vbios (but sounds like still needs the VBT)
- deliver a payload that has a path toward securing the boot process
(e.g. Heads) 3) deliver a payload that can still offer a user to install their own OS (thus allowing user-configuration and control)
2 and 3 don't need to be separate stages, although it might make sense to prototype them in two pieces to deal with ROM size issues. This is the approach the the Mass Open Cloud group is doing; their remote attestation infrastructure is currently in python and has both glibc and OpenSSL dependencies, so their Heads init script does a fetch, measure and extract of a tar file from the network. Porting it to work with libtpm and musl-libc is later on their roadmap.
So, I'll mention go userland one last time, for a simple reason: I have it on good authority that at some places, saying you have a go userland instead of a c userland checks a check box on a security checklist. I think that's a sensible decision, having watched all the awful ways that C programs tend to go wrong :-)
ron
-
ron minnich -
Sam Kuper -
Todd Weaver -
Trammell Hudson