The bootloader (being it grub, or something more simple as systemd-boot) is useful to me for a couple of reasons:

- it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start

- it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it

- it allows you to choose between multiple kernels and initrd images easily, again for recovery purposes

- it has a voice for entering the UEFI setup menu: in most modern systems again entering the UEFI with a keyboard combination is unnecessarily difficult and has a too short timeout

- it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so.

the title text says 'Loaded by the EFI stub on UEFI, and packed into a unified kernel image (UKI), the kernel, initramfs, and kernel command line, contain everything they need to reach the final boot target' which sounds like they're not talking about using two separate kernels, one for the bootloader and one for the final boot target, but rather only one single kernel. possibly that is not the case because the actual information is hidden in a video i haven't watched

https://news.ycombinator.com/item?id=40909165 seems to confirm that they are indeed not saying what you thought

edit: they're proposing both configurations

This sentence does not say "the bootloader is itself another, separate, Linux kernel", so I'm not seeing him saying what you're saying he seems to be saying.

This doesn't make sense. There's nothing in the post you responded to which could realistically be interpreted as making that point. And there haven't been any edits, which might have explained your confusion.

possibly you don't know this, but in order to run a kernel with a modified command line, the bootloader-kernel would need to run a second kernel, for example using kexec; linux doesn't have a useful way to modify the command line of the running kernel. that's why i interpreted the comment as saying that they are proposing using two separate kernels. in https://news.ycombinator.com/item?id=40910796 comex clarifies that they are in fact proposing using two separate kernels; the reason i was confused is that that's not the only configuration they're proposing

I would assume that in their proposed solution, the kernel would have logic to check for a CMDLINE flag (or rather, lack of any CMDLINE flags!) to indicate that it's operating in bootloader mode; and if decides that it is, then it never calls ExitBootServices. All the EFI stuff stays mapped for the whole lifetime of the kernel.

(Also, given that they call this a "unified kernel image", I presume that in the case where the kernel decides to boot the same kernel image that's already loaded in memory as the bootloader, then nothing like a kexec needs to occur — rather, that's the point at which the kernel calls ExitBootServices (basically to say "I'm done with caring about being able to potentially boot into something else now"), and transitions from "phase 1 initramfs for running bootload-time logic" into "phase 2 initramfs to bootstrap a multi-user userland.")

That's unlikely, I think that would mean you cannot use native drivers, at which point you're just writing another bootloader. I suspect they only planning to kexec into target kernel, not chainloading other EFI bootloaders.

> I think that would mean you cannot use native drivers

Yes, that's right.

> at which point you're just writing another bootloader

But that's not necessarily true.

Even if you could only use EFI boot+runtime services until you call ExitBootServices, in theory, an OS kernel could have a HAL for which many different pieces of hardware have an "EFI boot services driver" as well as a native driver; and where the active driver for a given piece of discovered hardware could be hotswapped "under" the HAL abstraction, atomically, without live HAL-intermediated kernel handles going bad — as long as the kernel includes a driver-to-driver state-translation function for the two implementations.

So you could "bring up" a kernel and userland while riding on EFI boot services; and then the kernel would snap its fingers at some critical point, and it'd suddenly all be native drivers.

Of course, Linux is not architected in a way that even comes close to allowing something like this. (Windows might be, maybe?)

---

I think a more interesting idea, though, would come from slightly extending the UEFI spec. Imagine two calls: PauseBootServices and ResumeBootServices.

PauseBootServices would stop all management of devices by the EFI (so, as with ExitBootServices, you'd have to be ready to take over such management) — but crucially, it would leave all the stuff that EFI had discovered+computed+mapped into memory during early boot, mapped into memory (and these pages would be read-only and would be locked at ring-negative-3 or something, so the kernel wouldn't have permission to unmap them.)

If this existed, then at any time (even in the middle of running a multi-user OS!), the running kernel that had previously called PauseBootServices, could call ResumeBootServices — basically "relinquishing back" control over the hardware to EFI.

EFI would then go about reinitializing all hardware other than the CPU and memory, taking over the CPU for a while the same way peripheral bring-up logic does at early boot. But when it's done with getting all the peripherals into known-good states, it would then return control to the caller[1] of ResumeBootServices, with the kernel now having transitioned into being an EFI app again.

[1] ...through a vector of the caller's choice. To get those drivers back into being EFI boot services drivers before the kernel tries using them again, naturally.

It's a dumb idea, mostly useless, thoroughly impractical to implement given how ossified EFI already is — but it'd "work" ;)

Do people really dual boot a lot in 2024? It was a good use case when virtualization was slow but decades after the CPU started shipping with virtualization extensions there is virtually zero overhead in using VM nowadays and it is much more convenient than rebooting and losing all your open applications just to start one on another OS.

> - it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so.

How many times in a decade are you running memtest?

Getting to UEFI firmware or booting another OS/drive is just a matter of holding one key on my thinkpad. I would just simply not buy and bad hardware that doesn't allow me to do that. Vote with you wallet damit.

I would also argue that you can perfectly have grub sitting alongside a direct boot to kernel in an UEFI setup. There are many other bootloaders than grub and users are still free to use them instead of what the distro is shipping. UEFI basically allows you to have as many bootloader as you have space on that small fat partition.

Yes.

> there is virtually zero overhead in using VM nowadays

Not for real-time audio production. The state of audio plugins having Linux support from vendors like EastWest, Spitfire, Native Instruments, iZotope is abysmal and even Wine does not run them nowadays.

Even with a virtual machine that has pinned cores and USB pass-through of a dedicated audio interface, it practically locks you to one sample rate, any change causes crackles, try to load more than one plugin and you hear crackles. There is plenty of overhead.

Yes, there are still use cases for it.

The state of GPU virtualisation, for example, is a spectrum from doesn't exist/sucks to only affordable for enterprise customers.

So unless you have a second graphics card to do pass through with, if you want to use your GPU under both OSes then you almost always have to dual boot (yes, there are other options like running Linux headless, but it's not even remotely easier to set up than dual boot)

One of the big problems is with the graphics cards, because the vendors block a driver functionality ( SR-IOV ) for consumer GPUs that would allow single GPU passthrough for VMs.

The alternative is to leave the system headless (reboot needed, and the VM need to run as root), or to use two graphics cards (wasting power, hardware resources, etc.), for which you also need to add an extra delay layer inside the VM for to re-send the graphics back to the screen, or to connect two wire inputs to the monitor.

While if don't dual boot you can switch completely to another OS and only use VM or remote desktop for the handful of use cases when you aren't ready yet (and then end ip abandoning them completely as well).

Keep in mind that booting takes a tiny fraction of the time today that it did in the 90s.

> - Possibility to chainload from Linux while using Secure / Trusted boot: Dual-booting, although not supported on RHEL, is important for Fedora. While there are attempts to kexec any PE binary, our plan is to set BootNext and then reset, which will preserve the chain of trust that originates in firmware, while not interfering with other bootloaders.

It could be seen as an advantage to do chainloading by setting BootNext and resetting. I think Windows even does this now. However, it certainly is a different approach with more moving parts (e.g. the firmware has to not interfere or do anything stupid, harder than you'd hope) and it's definitely slower. It'd be ideal if both options were on the table (being able to `kexec` arbitrary UEFI PE binaries) but I can't imagine kexec'ing random UEFI binaries will ever be ideal. It took long enough to really feel like kexec'ing other Linux kernels was somewhat reliable.

[1]: https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...

Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into System B on the next reboot?

If so, that's a pretty terrible experience.

Basically, System A's kernel boots. But, instead of immediately loading the System A userland, it loads a boot menu of systems that it reads from UEFI NVRAM and presents it to the user. So you select System B from the list, the menu sets BootNext in NVRAM and issues a reboot.

In practice, the main UX difference is that it takes a bit longer and you'll see the UEFI vendor splash screen again after selecting the boot option.

I'm not a user of Windows anymore but I seem to recall Windows doing something quite similar, where it had a boot menu that felt suspiciously like it was inside of Windows, and to actually change the boot target, it had to reboot.

I mean, it kind of is loading the System A userland. At least the initramfs of it. AFAICT in the proposal the bootloader would now be a regular userland program living in the initramfs.

I get the impression that the eventual goal would be to make this bootloader program into the "init(8) but for the initramfs phase of boot" — i.e. rather than there being a tool like update-grub that calls mkinitramfs, feeding it a shell-script GRUB generated (which then becomes the /init of the initramfs); instead, there'd be a tooling package you'd install that's related to the kernel itself, where you call e.g. kernel-update(8) and that would call mkinitramfs — and the /init shoved inside it would be this bootloader. This bootloader would then be running for the whole initramfs phase of boot, "owning" the whole bootstrap process.

What the architecture is at that point, I'm less clear on. I think either way, this initramfs userland, through this bootloader program, will now handle both the cases of "acting like a bootloader" and "acting like the rest of initramfs-based boot up to pivot-root." That could mean one monolithic binary, or an init daemon and a hierarchy of services (systemd: now in your bootloader), or just a pile of shell scripts like GRUB gives you, just now written by Redhat.

Many of the Linux systems I support don't have displays and EFI is supported through UBoot. In those cases you're using a character-based console of some sort like RS232.

A lot of those GRUB options could also be solved by embedding a simple pre-boot system in an initial ramdisk to display options, which maintains all of the advantages of not using GRUB and also gives you the ability to make your boot selection. The only thing GRUB is doing here is allowing you to select which kernel to chain-load, and you can probably do the same thing in initramfs too through some kind of kernel API that is disabled after pivot root.

Hardly a problem in my experience - just hold down the key while booting.

And dual booting is rarely needed anyway and generally just a pita. Just always boot into your preferred OS and virtualize the other one when you really need it.

> also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start

You can change the EFI boot entries including priority from the OS, e.g. via efibootmgr under Linux. Should be easy to setup each OS to make itself the default on boot if that's really what you want.

> it allows to edit the cmdline of the kernel to recover a system that does not boot, e.g. start in single user mode. That can really save your day if you don't have on hand an USB stick and another PC to flash it

All motherboards I have used had an EFI shell that you can use to run EFI programs such as the Linux kernel with efistub with whatever command-line options you want.

> it allows you to choose between multiple kernels and initrd images easily, again for recovery purposes

EFI can have many boot entries too.

> it has a voice for entering the UEFI setup menu

What does "a voice" here mean? Or you meant "a choice"? Either way, same as with the boot menu you can just hold down the key while booting IME.

> it allows you to boot any other EFI application, such as memtest, or efi shell. Most UEFI firmwares doesn't have a menu to do so.

In my experience the EFI shell has always been accessible without a bootloader.

I've been dual-booting linux since the kernel 2.2.x era and being able to do it was a major driver to migrate away from windows. It is super important for onboarding of new users that can't yet get rid of windows fully - mostly because of gaming (yes proton is nice, but anything competive that uses anti-cheat won't work yet is the majority share of gaming). And that is the reason I still boot into Windows on my dual-boot machine: Gaming. For me that windows is just a glorified bootloader into GoG or Steam, yet desperately needed and virtualization won't solve anything here.

Having to actually restart a PC is a pain in the ass which is why I don't dual boot.

is a pain in the ass? All the virtualization solutions are moot for gaming due to anticheat (plus 3d graphics virtualization not really working for windows)

For all laptops apart from Dell, Grub is the bootloader that EFI could never be.

Yes it does, I use it with two kernels, just have different entry for each stub in UEFI. Whenever I want to boot the non-default kernel I just hit F11 (for BIOS boot menu, on my motherboard) and choose the boot option. You just need to add the boot options in UEFI, pointing to the corresponding EFI files. They also have the kernel command line parameters baked into them and you can set your desired ones (silent boot whatever).

If I could do the same with something that is as small in terms of footprint, and is as flexible as GRUB is (we also PXE-boot into GRUB loaded from the network, both in BIOS and UEFI mode), then I'm interested.

Given that Windows tries to restore open windows to make it look like it didn't even reboot, I'm surprised they wouldn't make sure that the reboot actually goes back into Windows.

  GRUB_DEFAULT=saved
  GRUB_SAVEDEFAULT=true

At least this is what an Arch Linux derivative (Artix) system of mine does, amusingly. It sort of gives an observer the impression that it's an encrypted Windows system on boot.

You can use the UEFI shell for this. It's kind of a replacement for the old MS-DOG command line.

I'd have preferred CoreBoot or OpenFirmware, but the PC industry was too slow to move and let Intel -- still smarting from Microsoft forcing it to adopt AMD's 64-bit x86 extensions -- take control of the firmware.

UEFI is just a standard interface, not an implementation of a bootloader. This enables multiple UEFI compliant implementations as well as an easy way for OS to support all UEFI based bootloaders without needing to coordinate with the owner of the bootloader. While I'm sure most would agree the UEFI interface may not be ideal, it has a lot of industry momentum, and is therefore probably the best option to get behind. There are a lot of players in this space (mostly hardware vendors) and coordinating anything is very difficult and takes a very long time.

Windows Boot Manager can chainload into any arbitrary bit of code if you point it where it needs to hand off.

It's a feature that goes back to Windows NT (NTLDR) supporting dual boot for Windows 9x, but it can be repurposed to boot anything you would like so long as it can execute on its own merit.

eg: Boot into Windows Boot Manager and, instead of booting Windows, it can hand off control to GRUB or systemd-boot to boot Linux.

Except they've made it increasingly harder to do this over the years. Nowadays you have to guess when it is on the magic 1 second of "GRUB time" before it starts loading and then smack all the F keys and ESC key and DEL key at the same time with both hands and both feet because there is nothing on the screen that tells you which key it actually is.

All while your monitor blanks out for 3 seconds trying to figure out what HDMI mode it is using, hoping that after those 3 seconds are over that you smacked the right key at the right time.

And then you accidentally get into the BIOS instead of the GRUB.

It used to be a nice long 10 seconds with a selection menu and clearly indicated keyboard shortcuts at the bottom, and you could press ENTER to skip the 10 second delay. That was a much better experience. If you're in front of the computer and care about boot time, you hit enter. If you're not in front of the computer, the 10 seconds don't matter.

I know you can add the delay back, I just wish the defaults were better.

FreeBSD's loader does this, and its so much easier to deal with. Eg, it understands ZFS, and can pre-load storage driver modules and zfs.ko for the kernel, so that the kernel has everything it needs to boot up. It also understands module dependencies, and will preload all modules that are needed for a module you specify (similar to modprobe).

If you build the drivers for your storage media and filesystem into the kernel (not as a module), and the filesystem is visible to the kernel without any userland setup required beforehand (e.g. the filesystem is not in an LVM volume, not on an MD-RAID array, not encrypted), it is fully capable of mounting the real root filesystem and booting init directly from it.

The only point of consideration is that it doesn't understand filesystem UUIDs or labels (this is part of libuuid which is used by userland tools like mount and blkid), so you have to specify partition UUIDs or labels instead (if you want to use UUIDs or labels). For GPT disks, this is natively available (e.g. root=PARTUUID=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 or root=PARTLABEL=Root). For MS-DOS disks, this is emulated for UUIDs only by using the disk ID and partition number (e.g. root=PARTUUID=11223344-02).

You can also specify the device name directly (e.g. root=/dev/sda2) or the major:minor directly (e.g. root=08:02), but this is prone to enumeration order upset. If you can guarantee that this is the only disk it will ever see, or that it will always see that disk first, this is often the most simple approach, but these days I use GPT partition UUIDs.

In practice, we have generic kernels which require a lot of stuff in modules for real user systems running on distributions. Instead, though, we could have a loader which doesn't require this big relatively-opaque blob and instead loads the modules necessary at boot time (and does any necessary selection of critical boot devices). i.e. like FreeBSD does.

There's advantages each way. You can do fancier things with an initramfs than you ever could do in the loader. On the other hand, you can change what's happening during boot (e.g. loading different drivers) without a lot of ancillary tooling to recover a system.

- linux tells the bootloader what folder the modules live

- bootloader just puts them all in memory

- linux just picks what it needs.

That's all the initramfs is anyways. The point is there's no reason to prebuild an image from inside Linux, you can just have grub assemble a simple fs on the fly.

...But to load it at boot time it absolutely must be done through an initramfs. Is that right?

No, not AFAICS; it is incorrect.

On UEFI the system boots from a FAT32 partition. Put the kernel directly on that FAT32 partition, and any necessary modules such as ZFS, and the kernel can load the ZFS module from FAT32 and then mount root directly without any need for an initramfs.

This is how systemd-boot works.

I am not advocating systemd-boot -- I found it a pain to work with -- but the point is that it's perfectly possible and doable. The initramfs is a bodge and it's time we did away with it. It should only be needed for installation and rescue media.

Yes, because it cannot be part of the kernel image, or it would be illegal (a violation of the GPL license) to distribute that kernel. Therefore, it must be a module, and that module has to live somewhere and be loaded by something. If root is on ZFS, this must therefore live in an initramfs and be loaded by it so that the initramfs can mount the real root filesystem on the kernel's behalf.

That would probably make updates a lot less slower than having zfs shipped in an initramfs though.

Me too. I go back to within about 3 years of that.

But I expect my distro to handle this for me now.

If the distro compiled and updated the kernel for my hardware then there's be no need for an initramfs.

While initramfs was a simplistic kludge, the UKI idea does not fix it, it wraps a kludge inside a fugly ball of lack of understanding.

When I was young and spry, I used to compile them with every new minor revision. Now, it is just maybe a couple times per year. I think that cooling it on how often I do it has helped it not become annoying.

But initramfs isn't so bad, and it allows things like ZFS root to have a modicum of smoothness and integration.

That is a lot faster than recovering from a backup.

Though I only do it for my ARM based devices currently.

And if you're not throwing away build artifacts after each build, then getting stable updates is just a `git pull` and incremental make, which is usually very quick.

And also for e.g. cases where you've got some custom stack of block devices that you need to set up before the root FS and other devices can be mounted. It's not just about loading kernel modules.

I don’t see the point of doing so however.

There have been several attempts to add features to the grub zfs code over the years, but there are several maintainers of grub who happen to be employees of Oracle, and typically the attempts go nowhere.

I personally can't recommend using grub anymore. The whole "just make 2 pools" solution is unacceptable, and until Oracle stops gatekeeping, their code becomes more obsolete in my eyes.

You're reliant on the capabilities of the chip that you're working with, and a flaw in that can unravel everything that you've done. In one case, I had to disable the on-chip boot agent once things were provisioned because of flaws in their implementation.

In short, a signed applet could be sent to the chip to do things like read/write NAND or NOR, set fuse bits, etc. When an unsigned applet was sent, it was rejected as expected but they neglected to clear the memory contents in this case. So you could send a malicious applet, let it be rejected, and then just tell it to execute. It's kind of a fascinating writeup if you want to know more [1].

1. https://labs.withsecure.com/advisories/microchip-atsama5-soc...

Having lucked into using Lilo and no initramfs for several years now, I'm very happy with robustness and straightforwardness of the solution.

In contrast, on the rare occasion I've dealt with somebody elses' GRUB and initramfs setups, they turn out brittle and complex.

And if this bit is closed source, and something doesn't work, you don't have a recourse.

But then when it comes to the other points, yes I want to be able to reliably boot into other systems, but both systemd-boot and grub are notoriously bad at detecting other systems on disks (both use install-time detection IIRC). The only one which does a reasonable job is rEFInd. But even more a kernel with appropriate drivers could even add kernels/systems on usb disks to the selections (why do I have to go to the UEFI selection to boot from USB).

The next thing he completely ignores is booting into zfs or btrfs snapshots, which is not possible using systemd-boot AFAIK, and again would be much nicer to do with a kernel.

> [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes.

No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments.

> Loaded by the EFI stub

All the talk about booting the kernel directly is moot, because by this they mean "we will use systemd-boot" ;)

IMHO, this is part of the RH wider push for PKCS11/TPM2/FIDO2 stuff. So it is not really fixing boot loader, as it is standardizing on their bootloader "as the correct one" but using the kernel reputation on the double speak.

Just like they pushed the equivalent of https://www.tenforums.com/attachments/tutorials/195499d15314... as the interface of init. (i'm not salty on systemd, in fact i already use bootd even. but if you cannot see how systemctl is the same UX as that, you are blind)

Systemctl looks a lot like a modern init on another OS because a modern init on any OS looks a lot the same. Whether it should spawn 1800 subprojects is a different debate, but I for one am much happier maintaining trivial .ini like files than trying to teach the new engineer bash.

MILO could be installed as a boot entry in the firmware-level boot menu. MILO was a sort of stripped down Linux kernel that used its drivers to find and load the real kernel, ending with a kexec to hand over the system.

No matter how you slice it, I think you'll always come around to wanting this sort of intermediate bootloader that has a different software maintenance lifecycle from the actual kernel. It is a fine idea to reuse the same codebase and get all the breadth of drivers and capabilities, but you want the bootloader to have a very "stability" focused release cycle so it is highly repeatable.

And, I think you want a data-driven, menu/config layer to make it easy to add new kernels and allow rollback to prior kernels at runtime. I hope we don't see people eventually trying to push Android-style UX onto regular Linux computers, i.e. where the bootloader is mostly hidden and the kernel treated as if it is firmware, with at most some A/B boot selection option.

The code is here although it hasn't been touched it years: https://gitlab.com/samsartor/alamode-boot

Because that would only allow you to boot Linux kernels. One of the benefits of bootloaders is the ability to boot other OSs. You can’t kexec windows.

Every time I interact with it, I am struck by how awful it is, but the shell is just an EFI application so presumably one could replace it with something better written. Searching turns up EFI menus aplenty, but no one has (yet) taken a shot at a simpler, cleaner EFI shell from what I can see?

Actually wait. They at least haven't proposed to replace grub with systemd. Or is that buried in one corner of the presentation?

What I want is for each OS to install its loader in a unique directory to that OS instance, not unique to the OS vendor. Multiple Debians etc will argue over who controls /debian. You also have to bless UEFI with magic NVRAM variables when it could just scan my EFI System Partitions for any file named “loader” and present that as a boot option.

Perhaps I should just chain from UEFI to something smarter that skips the UEFI-standard and does this smarter thing instead? Debianised GRUB tries to be smart at update-grub time in order to detect OSs but it would be neater if the loader did it.

Edit: In fact I see this is exactly the goal of rEFInd https://www.rodsbooks.com/refind/ …in particular it laments how “EFI implementations should provide boot managers [but] are often so poor as to be useless” so it tries to do a better job for you. I’ll give it a go.

In each GRUBified OS instance, in /etc/default/grub (or on Debian and derivatives, to avoid altering the distro-shipped config file, /etc/default/grub.d/local.cfg ), set:

GRUB_DISTRIBUTOR=

This is used by grub-install.

If calling grub-install directly one can also pass --bootloader=id=

The value is set via efibootmgr's --label

First: Linux could already be booted directly from the UEFI manager. You don't need GRUB at all. So why a new scheme - why weren't they just doing that?

Second (and third, etc.): If I have multiple Linux installations along with a Windows installation, wouldn't this mean one of them now has to be the one acting as the boot loader? Could it load the other one regardless of what distro it is, without requiring e.g. an extra reboot? And wouldn't this mean they would no longer be on equal footing, since one of them would now become the "primary" one when booting? Would its kernel have to be on the UEFI partition...?

(And in principle this system could load other linux distros assuming there was some co-ordination in how to do so. Windows is more difficult, as is interaction with secure boot)

I indeed understood that part, but their motivation for this was security. If you want security, you should want to boot directly into the kernel. And if you're the occasional user who has multiple OSes installed in parallel... you can just add more kernels from your dual-boot installs directly to the UEFI screen; there's really no need to go through any form of intermediate stage, whether kernel-based or boot-loader-based.

What I'm trying to say is: as cool as this is from a technical standpoint, I just don't understand the root of the premise or motivation here whose optimal solution is this approach. Whom is RedHat trying to please with this? The small fraction of users who dual-boot Linux, or the rest of the users who just have a single install? And what problem are they actually trying to solve -- security, performance, or something else? Because the optimal solution to the first two doesn't feel like this one, unless they're targeting a niche use case I'm not seeing? e.g., do they have lots of enterprise users that boot off a network, but whom would rather have a local Linux install whose sole job is to boot that...?

In principle, the EFI multiboot mechanism should be the way to handle basic multiboot options. It would of course be nicer and cleaner from a design perspective not to have redundant mechanisms on top of each other. In practice, though, using the EFI boot menu can be clumsy. The real solution would be for it to not be clumsy but it doesn't look like we're necessarily there.

I think I can recompile the Linux kernel in around 15 minutes, but I have a 12400F. And 15 minutes is still 60 times longer than most people are willing to wait.

That sounds 1.5 to 2 seconds slower than just having efistub in your main kernel image, which honestly is a LOT. Of course not possible with problematic drivers like ZFS but then you don't have to use those.

> The graphics driver needs to be unloaded before a kexec, or the next kernel will not be able to gain exclusive control of the device. This is difficult to achieve manually because any programs which need exclusive control over the GPU (Xorg, display managers) must not be running. Below is an example systemd service that will unload the KMS driver right before kexec, which requires that you use systemctl kexec.

It also talks about ACPI issues and there was a question in the presentation although it was unintelligible. More generally, I could imagine more back and forward compat issues that wouldn’t arise from a simpler bootloader that is only initializing a very constrained amount of hardware whereas the kernel will try to boot the full HW twice. I hope they figure out how to make it work, but I suspect they’ll run into pretty significant challenges running this on real “legacy” HW until this is in the ecosystem enough that HW vendors will support it better. A bonus would be that kexec will become better supported and more robust over time if there’s broader adoption.

I also wonder if there’s any back/forward compat issues kexec between very different kernel versions, but I’m guessing the kexec mechanism was intentionally designed to support that as best as it can.

https://wiki.archlinux.org/title/Kexec

the more rope given here, the more will be taken, a rich programming environment of a whole kernel will I'm sure raise temptation to new levels of stuff here, and the natural progression from the shader framebuffer is hand-off to the next kernel stage so it can keep the animation going until wayland starts or whatever. maybe i'm paranoid.

Or, at least: I certainly didn't have to do anything to the kernel for it to work. I'm just running whatever Void Linux is rolling with right now.

[0]: https://docs.zfsbootmenu.org/en/v2.3.x/

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.

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/s...

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.

Taken to the limit, Oxide Computer boots using the [Pico Host Boot Loader](https://github.com/oxidecomputer/phbl) which is probably not suitable for your personal system where you would want to boot many OS images from many devices on many different mainboards using very similar or modular boot flash images.

Phbl transfers control to a partial Unix image, also in the boot flash, which brings in the rest of the OS from a well-known boot device. There is no UEFI, CoreBoot, PXE boot etc. The AMD PSP code does run, but that's the only early external blob in the boot path. This does mean that the OS has to understand its hardware, there is minimal "free" initialization.

  fs0:linux.efi root=/dev/nvme0n1p1 initrd=ramfs.img loglevel=2

In the bad old days, ROMs had very limited space. Lots of bootloader packages got invented, tiny things that knew just enough about ROM and the filesystem to get the 'real' code loaded, maybe un-zipped, maybe unencrypted. Later, some network-boot options which were handy.

Today? The boot flash is huge (compared to ROMs). You can put an entire OS in there! In fact, nowadays the bootloader is often a flash partition right next to other OS images.

I assert, there's nothing that a bootloader can do that an entire OS e.g. Linux image can't do. Just build a linux image, put a boot-script in there to allow network-boot or reboot-from-another-partition. And be done with it - no more u-boot, no more obscure bootloaders with limited drivers and options.

The day of the bootloader is over.

If you want to be able to do anything prior to calling ExitBootServices(), such as choose what EFI application you want to use and options you want to pass it, you need a service built to provide you that interface which itself does not call ExitBootServices().

The name of that service is the bootloader.

I see some other comments in this thread about hypothetically supporting booting other UEFI targets and some ideas on how that would be implemented.

There is a question in the video about chainloading around 27 minutes -- https://youtu.be/ywrSDLp926M?t=1640 but the answer isn't clear to me - "setting FE variables". Is that frontend? firmware environment?

> Reminder that not all platforms support or, indeed, can support kexec() sanely at all. Like ours. kexec() requires the ability to reset all peripheral state and that is impossible on Apple Silicon because firmware is loaded by earlier boot stages and cannot be re-loaded later to the reset state without a full system reboot.

Nothing for hacker to see and analyze the bootloader, assuming you did not load a driver to the NVRAM/Flash/UEFI/EFI.

Nice security compartment alization.

Redhat is smothering this easential security abstraction of 1st stage loader: not a good security model.

Like, as far as I can tell, grub or whatever is a bundle of filesystem and device drivers, with enough info to then execute a kernel.

Linux also is a bundle of filesystem and device drivers, but better tested ones I think.

To me, it seems like using the kernel's filesystem drivers, which you have to use already anyway once you've booted, means you have to trust fewer total implementations of these drivers, so it seems more secure.

What attack or threat vector are you trying to talk about here?

(Looking at you, systemd.)

You don’t allow access to the bootloader from any kernel, thereby afford a relative security in starting 2nd stage (kernels). One abstraction is that TPM, et. al., can lockstep assurances on each stage. At a minimum, you have a bootloader, in case of SNAFU/FOOBAR.

Bricking (or worse, malicious kernel) seems more a possibility with upcoming Redhat design.

> You don’t allow access to the bootloader from any kernel, thereby afford a relative security in starting 2nd stage

You install and update the bootloader and its configuration from your running linux system.

In this new world, you would also update the kernel from your running linux system. That's the same, right? To update the kernel, you need to update bootloader configuration anyway, so it's obviously required that the running system can at least update the kernel, and that's true either way.

> Bricking (or worse, malicious kernel) seems more a possibility with upcoming Redhat design.

If your kernel is malicious, it's game over whether or not you're using grub, right? Like, that doesn't seem like a new threat model.

I don't really care about bricking because, frankly, I've made my system unbootable via grub bugs more often than I have through kernel bugs, and the kernel developers seem to take these bugs more seriously, so I feel like bricking is a possibility with either design, but less likely without grub.

Either way, I need to have a liveusb off to the side to fix these issues.

I have programmed the ROM to instantaneously copy my ROM to RAM and run. The entire system is running instantly as soon as I power on. There is absolutely nothing else.

Because everything else is a big mess:

Intel ME, BIOS, UEFI, kernels are signed by companies with Microsoft's blessing, EFI, FAT, TPM, anything with the word "Secure" in it, ...

This allows a boot to happen in less than 5 seconds.

The 1% of times I need something different, I use the boot selector provided by the firmware to boot to grub (that's installed anyway), where I have the usual plethora of choices.

Is there a key to be pressed at the right moment? There is. I even have to insert a password. So what? I can go through such ordeal once in a while for that 1% of "special" boots.

Faster boot times and more secure installations are always advantageous. I'm all rooting for this development.

I've been wondering for a while why grub is still used, given that its basic architecture is outdated.

- inertia (don't rewrite something if it works; who really wants to own responsibility for testing this thing on all architectures GRUB currently supports?)

- multi-OS boot scenarios (I assume this new system will support that, but (a) I don't know for sure and (b) I don't really want to boot all the way into Linux just to throw Linux away and boot something else...)