I do like the coreboot + lightweight payload (such as u-boot or grub) approach, and simply can't see any benefit of jamming a Linux kernel in; Simplicity is itself value.
Even if I were to find their approach appealing (I don't), Linux's monolithic design with no driver APIs doesn't even seem like a good fit for this; NetBSD's kernel size (and its cleaner design, and the RUMP kernels feature), Minix3 (high assurance, unlike Linux) or even Genode are far better suited.
But, seriously, we need less, simpler, cleaner code, and this "jam Linux into everything" approach seems nothing less than the old "when you have a hammer, everything looks like a nail" problem.
Using Linux is simpler. Grub needs to replicated a ton of stuff that already is in Linux and it has worse more insecure and slower implementation.
Once you have a real Linux you can use all the battle tested code. You can easily and in good environment implement all the features you want in terms of boot verification, boot security, authentication, attestation and so on.
Using Grub and pushing ever more features into it is not simpler, and its not more secure.
Using a well tested Linux software that has long supported these features with a set of standard open source implementation for all the features you need.
On servers, you're already booting a Linux kernel. IMO, it's simpler to boot an older version of Linux that ultimately shares almost all the relevant code with your production version of Linux than to have two entirely separate codebases.
For example, if you fix a bug in an upstream Linux driver needed at boot time, then both your production system and your bootloader will automatically get it (once you rebuild and reflash). With the traditional UEFI setup, you have two separate codebases, each with their own sets of bugs. I don't see how that is simpler.
>For example, if you fix a bug in an upstream Linux driver needed at boot time
Or, for example, if there's a bug in a Linux driver, neither linux nor the bootloader (which is also linux) will work.
>With the traditional UEFI setup, you have two separate codebases, each with their own sets of bugs.
Except Linux is a multi-megabyte-clusterfuck, and the bootloader likely is simple and easy to understand/debug, and will keep working as long as the hardware it needs to boot remains the same, which is usually the case.
This "LinuxBoot" is trying to replace most (or all) of UEFI on systems it can support, not just grub. UEFI is also multi-megabyte, and arguably more of a "clusterfuck", forked from intel's UEFI upstream some years ago and sloppily adapted by motherboard vendors.
Most of us have not read the NetBSD kernel source code (I have not.) I've read a small bit of the Linux source code. Please inform me of why I should laugh at this claim.
Even if I were to find their approach appealing (I don't), Linux's monolithic design with no driver APIs doesn't even seem like a good fit for this; NetBSD's kernel size (and its cleaner design, and the RUMP kernels feature), Minix3 (high assurance, unlike Linux) or even Genode are far better suited.
But, seriously, we need less, simpler, cleaner code, and this "jam Linux into everything" approach seems nothing less than the old "when you have a hammer, everything looks like a nail" problem.