3 ms·

An EFI stub that sets up multi-boot, kernel and initrd then jumps into it is pretty simple. I don't know why people really need to keep putting huge intermedia

by raggi 2y ago

An EFI stub that sets up multi-boot, kernel and initrd then jumps into it is pretty simple. I don't know why people really need to keep putting huge intermediate loaders in every default boot path. If you want to boot more than one OS, yes you need one of these, but if you don't then there's no need for yet another OS instance in the boot path. The mid-stage should be extremely small and simple. There's been so much crying over the size of UEFI, well now there's an arbitrarily versioned and maintained entire Linux in there too? Mostly just to avoid some ugly UEFI APIs and a slightly different programming environment? Yuck.

raggi 2y ago
To state this slightly differently: GRUB has a terrible security story, a key point in the posted presentation. GRUB is huge and has design traps which contribute to regular developer mistakes. Any huge solution here will suffer the same problem, the larger it is the more likely the problem is. You don't really need much to do work here, a UEFI program can walk through the directories in the ESP and make choices, and perform assertions, so keep your A/B/R kernel and ramfs objects in there (as UKIs, as separate files, whatever). It can make a choice and boot the thing. If you want user choice you could put menus into that program too, but you don't need them for most users, so leave them out, that's a ton of deps gone. A basic program to do this isn't more than 1000 lines, it'll be low on maintenance and exceptionally low on critical flaws. It's not hard writing even fairly complex things for EFI, here's Fuchsia's UEFI stage which is designed for development and has far more features (fastboot, mdns discovery, etc) than most of these things need. It's still tiny compared to the grub stuff: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/firmware/gigaboot/ https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...
- snvzz 2y ago
  I'd say grub is crap, let's switch to das u-boot, which is not.
juped 2y ago
>If you want to boot more than one OS, yes you need one of these Nope, you only need refind (a fancy menu, not a bootloader at all), and only then because of how impoverished the vendor's boot menu always is; if your configuration is simple enough you could just use that despite it sucking.

by raggi 2y ago

raggi 2y ago

To state this slightly differently: GRUB has a terrible security story, a key point in the posted presentation. GRUB is huge and has design traps which contribute to regular developer mistakes. Any huge solution here will suffer the same problem, the larger it is the more likely the problem is. You don't really need much to do work here, a UEFI program can walk through the directories in the ESP and make choices, and perform assertions, so keep your A/B/R kernel and ramfs objects in there (as UKIs, as separate files, whatever). It can make a choice and boot the thing. If you want user choice you could put menus into that program too, but you don't need them for most users, so leave them out, that's a ton of deps gone. A basic program to do this isn't more than 1000 lines, it'll be low on maintenance and exceptionally low on critical flaws. It's not hard writing even fairly complex things for EFI, here's Fuchsia's UEFI stage which is designed for development and has far more features (fastboot, mdns discovery, etc) than most of these things need. It's still tiny compared to the grub stuff: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/firmware/gigaboot/ https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...

snvzz 2y ago
I'd say grub is crap, let's switch to das u-boot, which is not.

juped 2y ago

>If you want to boot more than one OS, yes you need one of these Nope, you only need refind (a fancy menu, not a bootloader at all), and only then because of how impoverished the vendor's boot menu always is; if your configuration is simple enough you could just use that despite it sucking.