Wow this is supercool: github.com/linuxboot/linu
Conversation
Replying to
Sounds like bloat to me. It's cool but it's also unnecessary attack surface
1
Replying to
Removing proprietary firmware with a small amount of open source is bloat? Increased attack surface? I’m confused
1
Replying to
You're shipping an entire linux kernel as a replacement for uefi firmware github.com/linuxboot/linu
How is that not bloated?
I doubt this stuff even has proper attestation support
1
The only place this MAY work is if you just want to directly boot linux on the server and use the same kernel but then you're unnecessarily overcomplicating the task of updating the kernel and initramfs and with how unstable linux is, what do you do when it won't boot?
2
Replying to
It’s replacing hundreds of custom UEFI modules that are likely not as robust as the Linux kernel drivers - your saying that’s “bloated” without a clear analysis of any of the practical alternatives - I think covered the choice pretty well trmm.net/LinuxBoot_34c3/
2
It would be nicer to load the OS itself much easier with a device tree passed to it for dealing with all the hardware details. Linux kernel has new LTS releases every few days with thousands of changes being made including to core code. Hardware setup is ideally data not code.
3
1
If you're at the point where you can load Linux, it seems like you might as well load the OS kernel and replace all the out-of-tree stuff for this with generic code reading device tree configuration. Can't understand why boot chains are such a ridiculously complex mess of stages.