18 ms·

No more boot loader: Please use the kernel instead

• StillBored 2y ago
  No, please don't. Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux. And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions? No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed. That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI. The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.
• drewg123 2y ago
  I personally think they're moving in the wrong direction. I'd rather have "NMIRFS" (no more initramfs). Eg, a smarter bootloader that understands all bootable filesystems and cooperates with the kernel to pre-load modules needed for boot and obviates the need for initramfs. 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).
  • sim7c00 2y ago
    this exactly. freebsd's loader is one of the only sane ones ive seen. grub is an amazing piece of software but its really a mess to work with.
  • ta8645 2y ago
    The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.
    • Muromec 2y ago
      I think the idea is, since modules map to device ids statically, bootloader could have enough information to read them from the filestem one by one. I don’t see the point of doing so however.
    • jolmg 2y ago
      > Initramfs is used for generic kernels where you don't know beforehand which features will be required. 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.
    • drewg123 2y ago
      I realize that. But every distro I've used uses an initramfs, so unless you want to build your own kernels, you're stuck with it, and the painfully slow initramfs updates when you update packages, and dkms (or similar) updates the initramfs with the newer version of your out-of-tree modules.
      • kbolino 2y ago
        Given the reason why "out-of-tree modules" exist, there's really no way to eliminate initramfs or something like it entirely in the general case. It might be possible to speed up the process of building the image (as long as the results are not "redistributed"), but this is a licensing and legal problem, not a technical one. FreeBSD is under a much more permissive non-copyleft license and so can legally bundle things that Linux cannot.
• theteapot 2y ago
  Isn't one of the use cases in GRUB choosing which kernel you want to load?
  • SahAssar 2y ago
    Via EFI probably.
    • m463 2y ago
      Does that mean the UI you will use to choose the kernel will probably be the bios?
      • Arnavion 2y ago
        Yes. If your UEFI doesn't have a good enough interface for selecting entries or temporarily modifying a kernel bootline, you can still use a bootloader, but a minimal one like systemd-boot instead of GRUB. All it does is show the text menu and then execute the UEFI binary for that entry, which in this case is the kernel's UKI binary, so all the heavy-lifting of LUKS, filesystem drivers, password entry, etc is done by the kernel and there's no complexity or duplication in the bootloader.
  • gjsman-1000 2y ago
    That’s the neat part - you install GRUB if that’s something you care about. For the 98+% who will always use the newest kernel, and can tell the system to (hypothetically) use a different kernel on future reboots after the system has loaded, it won’t be an issue.
  • Shorel 2y ago
    They address this use case in the video. Their loader can show a menu.
  • devit 2y ago
    You can use kexec to load a different Linux kernel from a Linux kernel. Probably slower and perhaps less compatible than using GRUB though.
• Arnavion 2y ago
  I can't open the .odp file right now, but: >We (Red Hat boot loader engineering) will present our solution to this problem, which is to use the Linux kernel as its own bootloader. 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. All necessary drivers, filesystem support, and networking are already built in and code duplication is avoided. That has been doable for a few years already. What's the new part?
  • alright2565 2y ago
    Maybe it's just a convenient script to put this stuff together? Looks like they have a website for this too: https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need-a-bootloader/ https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need... I'm not really sure I understand either, I've had this bootloader-free setup working great for quite a few years on my machines too.
    • Arnavion 2y ago
      Ah, so another Stratis then.
  • saghm 2y ago
    Right before that paragraph, they cite issues with GRUB as a motivation for this work. What confuses me is that Redhat already has a GRUB replacement in systemd-boot. Is this work intended to obviate that as well, or is it going to relate to it somehow? I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd).
    • Arnavion 2y ago
      >I imagine doing all this and tying it to systemd would generate some backlash like usual (although at this point, it seems unlikely that this would affect the plans given how few distros don't use systemd). systemd-boot is independent of systemd. It's called "systemd-" because it's under the same "group of core OS software" umbrella named "systemd", but otherwise it can be compiled independently, does not require the OS to be using systemd, etc. Edit: I also wrote originally that switching to systemd-boot would also require switching the kernel from vmlinuz+initramfs to a UKI, but I forgot systemd-boot does support vmlinuz+initramfs through explicit loader entries config.
• the_panopticon 2y ago
  Seems to be a trend including work like https://www.linuxboot.org/ https://www.linuxboot.org/.
• andrewstuart 2y ago
  I’m fairly technical but I have to say grasping the field of partitions , booting, boot loaders grub uefi its alternatives and the various combinations thereof in Linux defeated me. When learning something I try to find the simple path, a reliable minimum that gets to the goal. I never found it. Complexity is the word that comes to mind.
  • Muromec 2y ago
    Thankfully we have none of that on embedded. For every single board I have to figure out anew, so confusion is a purely transitive curse
  • andrewmcwatters 2y ago
    It's not that it defeated you, it's literally undocumented what you're supposed to do.
  • bradley13 2y ago
    Complexity, indeed. I haven't looked into this stuff in literally decades, but: I thought the purpose of a boot loader was to pass control to code belonging to the OS - which would then be responsible for loading it's own drivers, etc.. This solution sounds like starting an entire OS, only to boot the next OS. But then I think UEFI is also stupidly complicated, and ought to be whacked down to its core functions. Dinosaur, am I.
    • ziml77 2y ago
      I like that UEFI means I don't have to worry about bootloaders clobbering each other when multiple operating systems are installed on the same drive. They can all register into UEFI, rather than competing for the MBR.
  • benwaffle 2y ago
    Install arch with a couple of different bootloaders and disk layouts, and you'll learn it all. The simplest option is potentially systemd-boot + an unencrypted rootfs.
• linuxrebe1 2y ago
  I'm curious if they're proposal will be capable of handling multi-os boots. I know grub can, I can have Linux and windows and possibly even a third OS if I want. I am concerned that red hats solution the well-intended, may be rather myopic, and be commercial only. What I failed to understand, is what problem this solves for systems that I probably only reboot once or twice a year. (Given that it only works with Linux only systems)
  • FredFS456 2y ago
    You can switch OS's using the UEFI menu instead. It's not always convenient, depending on your UEFI implementation, however.
  • ack_complete 2y ago
    Yeah, look at Windows 10 if you want to see how this can be done poorly. Its boot menu works by booting Windows 10 first and then restarting the computer if you choose another OS. This includes going all the way through POST again. Took something like two minutes end-to-end to get to Windows 7.
    • zamadatix 2y ago
      I'm not sure I experienced the same with the Windows boot loader so maybe that behavior was something case specific instead of intended?
      • kasabali 2y ago
        That's the default behavior
        • fuzzfactor 2y ago
          If you Bcdedit, that is known as "Standard" bootmenupolicy, which is touch-screen compatible and it has to reboot in order to reach an alternative OS selection other than the current bootmgr default. If you bcdedit to be "Legacy" bootmenupolicy, you can select any OS from its simple non-touch text-based NT6 multiboot menu and it will boot right away without need for repost.
• Shorel 2y ago
  Kudos to the developers involved in this functionality. 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.
  • shadowgovt 2y ago
    I believe the two main reasons are - 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...)
• saltcured 2y ago
  This reminds me of MILO for booting Linux on some (?) DEC Alpha systems back in the 90s. I don't remember much about the actual firmware anymore. Much like today with UEFI, the system had some low-level UI and built-in drivers to support diagnostics, disk and network booting, etc. 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.
  • lagniappe 2y ago
    I remember LILO LInux LOader
    • slackfan 2y ago
      LILO is still perfectly functional. Works great with my slackware install on my workstation.
• fsniper 2y ago
  I was about to discuss/joke about the possibility of systemd absorbing this project. And hold and behold turns out there is already systemd-boot project competing in this space. I was not aware of that at all.
  • Spivak 2y ago
    systemd-boot is actually pretty great. If you're looking for a lean fast (multi-os) uefi bootloader systemd-boot is much easier to set up and less fiddly than grub. I haven't reached for grub in years.
    • zamadatix 2y ago
      I nearly did systemd-boot last install but grub2 behaves better if the motherboard is upgraded/otherwise factory reset so I shied away.
  • Arnavion 2y ago
    systemd-boot can be compiled and used independently of the booted OS using systemd. It also started out as gummiboot, unrelated to systemd.
• deleted 2y ago
  [deleted]
• andrewmcwatters 2y ago
  The Linux kernel is pretty easy to compile[1], but the first-party documentation for getting Linux to boot is total garbage. It's embarrassingly bad. You end up reading third-party articles to figure out what the modern approach is to building your own Linux-based operating system, but even then, it's effectively undocumented how you're supposed to get out of a RAM fs from a ISO boot. You're on your own. I completely reject the premise that Linux From Scratch is the way to do things, as walking through those steps, it's clear there are completely arbitrary steps thrown in, and as a result, it's basically its own distribution. What I'd like to see is official documentation for: + Building Linux (exists) - Creating an initramfs image (conflicting resources) - Making a bootable image (conflicting resources) - Installing the bootloader and Linux to a target disk (no resources available) You can do the first three easily if you know exactly the right magic incantations, and use GRUB, but then you're once again on your own. Once you've built Linux, the experience is you get to hold it in your hand and go "this is worthless." The Linux documentation flips between recommending initramfs and not, and also pointing you to documentation that is so old it's completely irrelevant and should be removed from kernel.org. I am never surprised the Linux desktop experience has been bad for decades, because no one cares about creating a decent installer process to begin with. You fail right out of the gate, and it makes the entire Linux bazar experience look like amateur hack hour. [1]: https://github.com/andrewmcwatters/linux-workflow/blob/main/.github/workflows/makefile.yml https://github.com/andrewmcwatters/linux-workflow/blob/main/...
  • rcxdude 2y ago
    What is your actual need here? You talk about confusing documentation for a low-level process which basically no user is expected to go through if they aren't exploring the foundations of a linux system, or a developer working on their own distribution, and then complain that this is a lack of "a decent installer process".
    • andrewmcwatters 2y ago
      It’s in the post, can’t you read? Also, something being low-level has nothing to do with documentation.
• yjftsjthsd-h 2y ago
  This kinda sounds like zfsbootmenu but without the ZFS. Which makes me wonder how hard it would be to factor out the ZFS bits and just use zfsbootmenu on other filesystems.
  • E39M5S62 2y ago
    It'd be doable, but not with out a whole lot of hacking on it. The internals of ZFSBootMenu are tied very tightly to ZFS. Though at that point you'd largely be reimplementing https://github.com/open-power/petitboot https://github.com/open-power/petitboot - which probably would be easier to port to x86_64 as an EFI application.
• samsartor 2y ago
  My previous laptop was a Chromebook running Linux+Coreboot. Unfortunately the usual Tianocore UEFI BIOS people use had some bugs in the nvme and keyboard drivers, which I gave up fixing or working around (at the time). Obviously Linux had working drivers because that's all ChromeOS is, so we setup a minimal Linux install as the Coreboot payload in the firmware flash, and I wrote a little Rust TUI to mount all visible partitions and kexec anything that looked like a kernel image. It worked like a charm and had all kinds of cool features, like wifi and a proper terminal for debugging in the BIOS! Based on that experience I don't see any reason why we don't just use Linux direct instead for everything. Why duplicate all the drivers? The code is here although it hasn't been touched it years: https://gitlab.com/samsartor/alamode-boot https://gitlab.com/samsartor/alamode-boot
  • jmb99 2y ago
    > I don't see any reason why we don't just use Linux direct instead for everything. 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.
    • benstoltz 2y ago
      You can kexec Windows: https://www.platformsecuritysummit.com/2019/speaker/koch/PSEC2019-LinuxBoot-Chris-Koch.pdf https://www.platformsecuritysummit.com/2019/speaker/koch/PSE...
• 201984 2y ago
  What's the point of using this over plain EFISTUB? I use it with Arch, and whenever I want to boot to Windows, I just use the BIOS menu. I don't see what benefit a Linux-based bootloader provides.
  • _ache_ 2y ago
    I do the same. The only advantage I can think of is editing kernel boot option on boot.
    • account42 2y ago
      If your EFI isn't shit you should be able to use the EFI shell to launch the kernel with whatever commandline you want.
  • pzmarzly 2y ago
    EFISTUB requires recompiling the kernel every time initramfs, microcode or commandline change, no? That would get annoying pretty quickly on desktop PCs, which are not that fast with recompiling, and would need to do all of this quite often, e.g. on nvidia driver updates.
    • 201984 2y ago
      I've never once had to recompile the kernel on my laptop for any reason. The kernel command line is set in the bios entry, which is somewhat tedious to change, but that's just an efibootmgr command. Initramfs gets rebuilt by pacman on larger updates, but that would happen no matter what bootloader I use.
      • mjg59 2y ago
        Vendor support for the command line coming from the EFI boot entry is of variable quality. If it works for you that's great, but unfortunately there's a bunch of boards in the wild where it doesn't. It's not a great solution for general purpose distributions as a result.
    • 2y ago
• lofaszvanitt 2y ago
  Also create a boot please that rivals w10's almost instant boot process. I just hate the current slow/non parallel boot process.
  • bayindirh 2y ago
    Many of our systems boot under 10 seconds after GRUB. You can make GRUB menu to timeout quickly or be completely hidden if you want. A modern system with a connected network can boot quite fast. Windows' instant boot is not boot actually, it's thawing hibernation. One of the biggest features touted by systemd is "embarrassingly parallel" booting capabilities, which Parallel SYS-V already sported. IOW, Linux already can boot pretty quickly given no hardware device is holding it back.
    • lofaszvanitt 2y ago
      Not fast enough.
      • bayindirh 2y ago
        What I was talking about was not virtualized. VMs start even faster. On the other hand, if you need to restart that much, you're really doing something wrong.
        • lofaszvanitt 2y ago
          There is always room for improvement. Like if you set the initramfs dep based, the whole process speeds up, but on a kernel upgrade it tends to error out. Why? Why enumerate usb devices on boot, when you have zero devices that need usb? Raid speed testing... and the list goes on.
          • bayindirh 2y ago
            > Why enumerate usb devices on boot, when you have zero devices that need usb? Are you sure? On servers there are generally a couple of USB based devices which handle BMC, hardware debug logging, etc. Just because you don't have physical ports, this doesn't mean the USB bus is empty and silent. When you connect to a server via BMC and request the console, you get two USB devices at least. One for mouse, one for keyboard. More devices appear if you attach virtual volumes remotely. > Raid speed testing... Because Linux kernel is stateless. There's no guarantee that you're booting on the same processor (make, model, family, even system bus layout) as the last boot. Moreover, there's no guarantee that you're not rebooting because of an unmaskable MCE which is fired because you lost half of your vector units (SSE/AVX blocks) or half of your FPU units, or any other CPU IP block (because you fried them) and you're in limp mode now... I have seen tons of these events and similar ones first hand. I'll prefer my systems to spend three more seconds to boot successfully so I can debug them rather than the kernel makes some assumptions and catches fire in a completely unrecoverable state leaving me stranded.
• Animats 2y ago
  Or, really, use the ROM's boot loader. This is getting closer to the way QNX booted decades ago. The boot image has the kernel and whatever user space programs and .so files you decide to include. For a deeply embedded system, you might not have a file system or networking. For desktop QNX (discontinued), you'd have some disk drivers, a file system driver, a network driver, and a shell, along with a startup script, to get things going.
  • bregma 2y ago
    QNX still works that way. It's just no longer free.
    • Animats 2y ago
      And the desktop environment is gone.
• alerighi 2y ago
  It's something you can do since a lot of years. I used to do so 10 years ago, when I've got the first motherboard with UEFI. But is it useful? It saves a minimal time in the boot sequence, but at what cost? 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.
  • michaelmrose 2y ago
    The suggested system would use bootnext to allow you to boot to windows. You could also put something in front of it like reEFInd
  • ec109685 2y ago
    Just because the boot loader is using Linux, it doesn’t prevent an alternative OS from being booted into, so there is nothing fundamentally stopping all of grub’s features from working in this new scheme.
    • jchw 2y ago
      It is a bit more complex, though. Quoting "nmbl: we don’t need a bootloader" from last month[1]: > - 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-a-bootloader/ https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...
• bastien2 2y ago
  Except that doesn't work in the real world, where encrypted and authenticated boot disks are increasingly common. So you'll need a significant amount of code that isn't the permanently-resident kernel that has enough device support to access keys and decrypt and authenticate what holds the kernel that will launch the OS. IOW, you'll just have to reinvent a bootloader anyway. Or you can address the problems with GRUB, extend it to do what you need, and avoid doing the traditional linux folly of Yet Another Unnecessary Reinvention. Or was systemd vendor lock-in not enough for your shareholders?
  • ec109685 2y ago
    Isn’t their argument that much of this code already exists in Linux?
  • mjg59 2y ago
    The EFI system partition is, by definition, either not encrypted or is unlocked by the firmware - your bootloader wouldn't work otherwise. In this setup, you just stick the UKI on the EFI system partition, and unlocking the rest of the drive is performed in the initramfs.
  • rcxdude 2y ago
    This code already exists in UEFI in the form of secure boot. The 'bootloader' (more accurately 'boot menu' IMO) kernel and its initramfs would be authenticated and unlocked by the system firmware, and then authenticate and unlock the rootfs and (optionally) different kernel for that system. It's basically going "hey, GRUB is more or less re-inventing the linux kernel, why don't we just write a simple userland for linux that does the same job but with way less code instead?"
    • BobbyTables2 2y ago
      Actually I don’t think UEFI firmware validates the initramfs — that is loaded by the kernel’s efi stub. One can make a UKI image which glues the two together in a single file along with a tiny bit of code for booting it.
• michaelt 2y ago
  Ah yes, unified kernel images. Finally, an end to the tiresome and obsolete notion of Linux running modified versions of the Linux kernel. With unified kernel images, Linux users can finally be confident knowing their kernels are signed by companies with Microsoft's blessing, such as Red Hat and Canonical - and Linux will be have proper support for the use cases of companies like TiVo, who want to run Linux, but also want to ensure the device owner can't make any modifications to the software on their device. This will be well worth it, to protect against the ever present issue of criminals breaking into my hotel room, finding my unattended laptop, and deciding not to steal it to sell on ebay - but instead to secretly modify my initramfs. I don't know about you, but I've had two covert CIA teams rappel in through my window this week alone.
  • mjg59 2y ago
    Any signature on a UKI is only relevant if you have secure boot enabled, and if you have secure boot enabled using the generally trusted keys then you're already not able to boot unsigned kernels. If you want to run arbitrary kernels then either use keys under your control (which UKIs support) or turn off secure boot - UKIs change absolutely nothing here.
• cbarrick 2y ago
  I developed a tool for managing EFI boot entries for my personal use. I've been meaning to get it ready to release publicly. It's mostly there, just a bit manual to install. https://efiboot.cbarrick.dev https://efiboot.cbarrick.dev
• peter_d_sherman 2y ago
  >"Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes." We agree thus far -- that GRUB may create unnecessary complexity and security holes (Note the relationship between "complexity" and "security holes" -- where you find one, you will usually find the other... they're intertwined like Yin and Yang -- you usually don't get one aspect alone by itself -- without also getting the other...)... >"Loaded by the EFI stub on UEFI" "Er, begging the question Governor" but isn't EFI and UEFI also a bootloader? Aren't those systems also complex? I think the article is trying to make the point that a small EFI stub program which loads a larger program, in this case, a modified version of the Linux Kernel itself could easily be audited for security issues, and yes, that's sort of true -- but remember that the EFI loader, no matter how small, still has to run in the UEFI environment, and the entire UEFI environment is anything but not complex... Phrased another way, running a tiny open source, secure program on a gigantic, complex black-box VM with many undocumented/opaqued/"black box" parts -- may not be all that secure... Still, any small part of a system that could be made simpler despite there being other obscure "black box" undocumented or poorly documented complex components at play -- is definitely a step in the right direction towards full future transparency and auditability...
  • mjg59 2y ago
    The UEFI environment is a given, unless you're in a position to replace the firmware - using grub doesn't avoid it in any way. But for the most part the security properties of the underlying firmware don't matter that much if the attack surface it exposes can only be touched by trusted code, which is the case if secure boot is enabled (and if secure boot isn't enabled then there's no real reason to bother attacking the firmware, you can already just replace the OS)
    • peter_d_sherman 2y ago
      The UEFI environment does not exist on older PC's. UEFI started to become mainstream around 2013 -- that is, an increasing amount of PC motherboard manufacturers started to put it on motherboards (rather than the older BIOS) around this time. It should be pointed out that on some motherboards the UEFI software may be placed on an IC (EPROM, EEPROM (Electrically Erasable Programmable Memory), Flash, NVRAM, ?) -- which may be writable, or writable under certain conditions (i.e., if the boot process doesn't load software which explcitly blocks this when the system starts up, or if such blocks, once existing, are bypassed, by whatever method...) If the UEFI-storing IC is writable (or that IC replaceable, either via socket or solder), then the UEFI (again, under the proper conditions) is subject to modification then it is modifyable; changeable; updatable, programmable; etc. etc.; use whatever linguistics you deem appropriate... >"The UEFI environment is a given, unless you're in a position to replace the firmware" If what I've written above is the case -- then any such UEFI envrionment (aka "firmware") under such conditions is very much replaceable! And if it is replaceable, then that firmware code can be made simpler by somone "rolling their own" -- and replacing it! Now that I think about it, I'm going to have to do more research for the next motherboard I buy... if it has to have UEFI on it, if I am compelled to buy a UEFI motherboard, then I want that UEFI firmware to be overwriteable/customizable/modifyable/auditable -- by me! Also -- I'd never trust "trusted" code implicitly... Didn't Ronald Reagan so eloquently say "Trust -- but verify?" It's the but verify part -- that's key! Anytime a security vendor or vendor (or any authority or "authority" for that matter) tells me to trust or "trust" something, my counterquestion is simply as follows: "Where is the proof that the thing asking for my trust is indeed trustworthy?" In other words, "How do I prove that trust to myself?" ? In other words, "Where is the proof?" ? And let's remember that proof by analogies (Bjarne Stroustrup) and proof by polled social approval consensuses ("4 out of 5 dentists recomend Dentyne for their patients that chew gum") -- are basically fraud... Anyway, your assessment, broadly speaking, is not wrong! It's just that there are additional "corner cases" which require some very nuanced understandings... Related: https://en.wikipedia.org/wiki/Open-source_hardware https://en.wikipedia.org/wiki/Open-source_hardware https://en.wikipedia.org/wiki/Right_to_repair https://en.wikipedia.org/wiki/Right_to_repair https://en.wikipedia.org/wiki/Non-volatile_memory https://en.wikipedia.org/wiki/Non-volatile_memory https://libreboot.org/ https://libreboot.org/ https://www.coreboot.org/ https://www.coreboot.org/ https://en.wikipedia.org/wiki/Open-source_firmware https://en.wikipedia.org/wiki/Open-source_firmware
• vlovich123 2y ago
  I really like the idea and the approach. I’m a little concerned however about the compatibility issues with kexec. For example, here’s what Arch says about the NVidia module: > 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 https://wiki.archlinux.org/title/Kexec
  • mjg59 2y ago
    There's no reason to load things like the nvidia driver if all you want to do is offer a choice to kexec into another kernel, which makes things easier - you can continue just using the display environment the firmware set up.
    • vlovich123 2y ago
      I think you’re missing the broader point I was trying to make by hyperfocusing on 1 example of an issue that can arise from kexec and is solvable in a number of ways. Ultimately the critique raised in the video about focusing on the VM and not trying this on real HW yet is a very real one and is the single hardest problem here I suspect, so punting on it can’t go on for too long.
• AtlasBarfed 2y ago
  Another red hat "improvement" that causes another decade plus of churn and documentation and support chaos?
• unixhero 2y ago
  Awesome, finally.
• Aissen 2y ago
  Considering distros serious about booting are effectively shipping grub forks with tens (debian) to over a hundred (ubuntu) to hundreds (fedora) of patches on top, it might be time to invest a bit more into Open Source early-stage booting. I'm doubtful that efistub + UKIs will solve all the problems, but I'm cautiously optimistic. Wait and see!
• tristor 2y ago
  I do UKIs and direct boot them on Arch. Works great. Do have to recompile for every change, but it's very fast on a modern system, takes about 40 seconds on my laptop.
• benstoltz 2y ago
  One can trade run-time flexibility for size, speed, and small attack surface. Taken to the limit, Oxide Computer boots using the [Pico Host Boot Loader](https://github.com/oxidecomputer/phbl 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.
• Dwedit 2y ago
  You had the bootloader because first you needed executable code in the first sector of the partition, and you can't fit much in those 512 bytes. But moving to UEFI means you never execute that code anymore. Instead, you load a BOOT.EFI file off of a FAT16/FAT32 partition. If there's a restriction on size for that, then you proceed to a bootloader instead of the real kernel.
  • dvhh 2y ago
    That's for the case for MBR partition type, I really hope we moved to more modern alternatives
    • creshal 2y ago
      GPT puts no size limitations on the FAT32 EFI System Partition. Your bootloader can be as big as you want it to be, which is why just booting off of a Linux kernel image with an initrd in the same file has been a valid option for years. Not sure why Lennart feels compelled to reinvent this particular wheel again.
• josephcsible 2y ago
  Does "security" here mean security from the computer's owner, i.e., Treacherous Computing? If not, then what kinds of security holes are even possible at the point when GRUB is running?
  • mjg59 2y ago
    grub consumes a bunch of untrusted material (splash pictures, fonts, filesystems, executables, and more) and parses them. grub's also written in C, which is pretty much the worst case for writing parsers. Someone able to replace any of these with something that triggers a vulnerability in grub is then able to, for instance, take control of your boot process and obtain your disk encryption key or user password or any other secrets you enter. (I don't want to seem like I'm picking on grub here, it wasn't written with this threat model in mind and it does a lot of things and achieving all of this stuff securely is hard)
    • josephcsible 2y ago
      Isn't everything that GRUB reads only writable by root? Is the threat model that root is the attacker?
      • mjg59 2y ago
        Or by anyone with physical access to your system, but also root isn't the same as the kernel - if your boot chain is fully verified then even root can't replace the component asking for your disk encryption key, and can't extract it from the kernel afterwards (assuming a secure kernel)
        • josephcsible 2y ago
          Can't someone with physical access to my system also pull out the hard drive, edit it however they want, and change Secure Boot settings too? And I don't want there to be anything even root can't do, since then there's stuff I can't do to my own computer.
• pmarreck 2y ago
  No thanks. NixOS lets you pick the generation at boot via GRUB. This is extremely useful.
• mjg59 2y ago
  A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some more explicit criticism at https://lwn.net/Articles/981149/ https://lwn.net/Articles/981149/ and I think that's a much more interesting set of concerns.
  • rcxdude 2y ago
    I feel like that post misses the biggest one that pulls people to GRUB: complicated boot sources and procedures. Filesystems that UEFI doesn't understand, more complex network boot sources, all that kind of complex messiness that GRUB enables and others don't. Now, whether those are good idea or not is a different question, but I think this is a good concept for a full replacement for GRUB, as opposed to the existing replacements which already cover the 90% case pretty well. (And I think it's got a case for handling the other cases OK: from the sounds of it they plan to lean on UEFI and A/B image to handle fallback, and it'll basically just work as a direct UEFI boot in the common case)
  • cycomanic 2y ago
    I have to say I find Lennart's arguments quite unconvincing. As another person said, the vast majority of people just want default boot to the most recent kernel (which this proposal could do well). 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.
    • Certhas 2y ago
      Also, from what I understand after watching some of the video demonstration in the Q&A, I could just have another EFI entry point towards the nmbl configuration with a grub like menu, and get an exact replica of the grub experience. Having to go through the BIOS boot menu for those rare occasions where I need it is perfectly reasonable.
• DEADMINCE 2y ago
  I have a bootloader signed with my own keys to boot my kernel. Nothing else will be able to boot the machine. I couldn't have this setup without a bootloader.
  • worthless-trash 2y ago
    You absolutely can sign the kernel with your own keys. This would allow you to boot your machine into the first level kernel without the bootloader. Is this 'couldn't' a self imposed requirement or a technical one I can't think of ?
    • DEADMINCE 2y ago
      > Is this 'couldn't' a self imposed requirement or a technical one I can't think of ? Probably not technical. There is another element, obtaining a HDD encryption key from the TPM. The idea that the HDD is encrypted outside of my laptop and nothing can boot on my laptop that isn't my signed OS to read it. Thinking about it I probably could do everything in the kernel directly - why not? Well, because it would be extra work to write all that, but probably not a technical limitation.
      • worthless-trash 2y ago
        Just to be clear, this is signing for validation not encryption of the contents. I wrote a guide on this topic of ensure platform integrity of system level (See https://wmealing.github.io/tpm-pcr07.html https://wmealing.github.io/tpm-pcr07.html ) its not too hard.
        • DEADMINCE 2y ago
          > Just to be clear, this is signing for validation Yup. I was just referencing wanting to obtain keys from the TPM to decrypt a partition. This is useful for me to have the following setup: - Laptop turned on, no keys pressed, boots into super locked down guest OS. - Laptop turned on, certain key pressed within 2 seconds, boot into 'hidden' OS. - In both cases, HDD is encrypted, decrypted automatically via retrieving keys stored in the TPM. This means the harddrive cannot be read outside of that particular laptop, unless keys are extracted from the TPM. - Bootloader signed with own key, any and all existing keys wiped, so laptop cannot be booted with any external OS. How would I recreate that setup with nmbl? That's a good link by the way, thanks - saved.
• dataflow 2y ago
  I've thought about something like this before, but I have so many questions on just the basic premise... 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...?
  • rcxdude 2y ago
    Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead (which has the advantage of requiring much less effort and code duplication). It's functionally very similar to GRUB, including with regard to your last point: generally speaking at the moment one OS needs to be managing the boot menu, and when they fight over it things go badly (see the status quo where Windows will occasionally just insert itself as the default after an update). UEFI could in principle have fixed this, but the inconsistent implementation between vendors makes it an unreliable option for OS developers. (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)
    • dataflow 2y ago
      > Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead 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...?
• jagrsw 2y ago
  I get truly confused when using GRUB. Maybe it’s just me being unwilling to dive into all the details, but seriously, why are there like 30 packages starting with 'grub' under Debian? All I want is to boot my kernel under EFI, and the package choices are overwhelming. grub-common grub2 grub2-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-efi-amd64-signed-template grub-efi-amd64-unsigned grub-efi grub-pc grub-pc-bin Do I need to mix grub2 and grub packages to get it to work? Currently I do, and a bit afraid to remove one or the other :) Usually, I end up trying things randomly (leaving some funny mess in /boot/EFI b/c not sure if --efi-directory should contain /boot/EFI prefix, or just /boot or nothing), then running some semi-random grub-install command, and eventually, it starts to work. But this is far from intuitive.
  • lmm 2y ago
    > Maybe it’s just me being unwilling to dive into all the details, but seriously, why are there like 30 packages starting with 'grub' under Debian? All I want is to boot my kernel under EFI, and the package choices are overwhelming. Debian packaging policy is insane, that's nothing to do with grub. On a regular distribution there is one (1) grub package (e.g. I just checked Slackware and Gentoo).
• kevinoid 2y ago
  This approach sounds similar to Petitboot <http://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html http://www.kernel.org/pub/linux/kernel/people/geoff/petitboo...> which is a kexec-based bootloader that I used on the Playstation 3 many years ago. Apparently it now targets many other systems and there is a (dead?) fork for Coreboot <https://github.com/ArthurHeymans/petitboot_for_coreboot https://github.com/ArthurHeymans/petitboot_for_coreboot>.
  • hackernudes 2y ago
    The Q&A mentions this[1] and says Petitboot requires two kernels (one minimal one + one normal one). NMBL just uses one single kernel for both steps. [1] around 23m20s https://youtu.be/ywrSDLp926M?t=1400 https://youtu.be/ywrSDLp926M?t=1400
• hackernudes 2y ago
  In the "what do we have so far?" slide they explain there are currently two variants of NMBL, one that does a switch_root (like a normal initramfs) and one that does kexec (to boot into a new kernel). It presents a menu for the user to select what to boot. It also will allow rolling back to the old version when boot fails. 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 https://youtu.be/ywrSDLp926M?t=1640 but the answer isn't clear to me - "setting FE variables". Is that frontend? firmware environment?
• JoeAltmaier 2y ago
  Not sure why loaders are a separate beast any more. 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.
  • nickelpro 2y ago
    The reason is very simple, you only get to call ExitBootServices() once (absent hacks that hook the function). 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.
    • JoeAltmaier 2y ago
      ...which should simply be another build of a real OS. Not some weird beast we inherited from the bad old days of tiny ROMs.
• CodeWriter23 2y ago
  So, move all of GRUB’s complexity into the kernel (or tell users to abandon all their use cases that led to the aforementioned complexity)
• ahmetozer 2y ago
  I have been used similar approach at embedded system to copy data ram and kexec kernel there
• 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.
• E39M5S62 2y ago
  It's nice to see more people embracing the capabilities of UEFI and Linux. ZFSBootMenu has been shipping an EFI application (really, a UKI masquerading as one) for almost four years now - https://docs.zfsbootmenu.org/en/v2.3.x/ https://docs.zfsbootmenu.org/en/v2.3.x/ . The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amount of pre-boot functionality.
  • account42 2y ago
    > The neat part is that the first stage kernel boots in roughly 1.5 to 2 seconds. It's not really appreciably slower than other boot methods while at the same time exposing a substantial amount of pre-boot functionality. 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.
    • E39M5S62 2y ago
      Yes, and then your main kernel image is no longer on ZFS and you lose the ability to reliably roll back your root dataset. Everything is a trade off. I reboot my workstation once a week for a kernel upgrade, so an extra 2 seconds of boot time isn't even a consideration.
• jkhjkhkjh 2y ago
  [dead]
• teo_zero 2y ago
  I'm a big fan of compiling my own kernel with all needed drivers compiled in, with the EFI stub compiled in, no initram, no grub, a fixed cmdline that works 99% of times. 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.
  • qhwudbebd 2y ago
    I completely agree, over time I've found myself moving to doing exactly this on every system I run. On UEFI systems, I can use the UEFI shell to add kernel command line options or launch a fallback kernel if I've screwed up badly enough to break boot. I don't need yet another layer of clunky menus and indirection.
• jkhjkhkjh 2y ago
  [dead]
• joveian 2y ago
  This link that has been posted a couple of times is a much better source for those of us who aren't going to watch a video: https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need-a-bootloader/ https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...
• msla 2y ago
  I can't wait until the big distros decide multi-booting is a feature "nobody uses" that "never worked" and therefore isn't going to be supported because "everyone can use VMs" and containers and whatever other solutions that do not, in point of fact, solve the problem. https://en.wikipedia.org/wiki/Multi-booting https://en.wikipedia.org/wiki/Multi-booting
  • account42 2y ago
    It does make sense for most distros to not care about that TBH. Advanced users can always put a boot menu in front of whatever their distros provide if the EFI-provided menu isn't sufficient.
• nardi 2y ago
  Meta: Can someone with Linux/bootloader knowledge tell me whether most of these comments are as clueless as they seem?
  • juped 2y ago
    Many seem a bit confused but I have only skimmed the comments. I don't understand the point of the thing described in the OP (I have not watched the talk, just skimmed the notes), myself. Linux kernels can EFI load themselves; if you want more flexibility than a precompiled kernel command line, or to load from ext4/other non-FAT filesystems, refind exists, fits on the ESP (kernel + initramfs can get big; I keep mine on the ESP but wanting to keep it on a larger ext4 filesystem is very understandable) and is very high quality. Bootloaders are obsolete in this sense; every OS provides an EFI stub loader, except Linux where kernels are their own EFI stub; nevertheless, distros continue to install GRUB alongside themselves on UEFI systems out of inertia. If Red Hat wants to supplant it... okay, but it can be supplanted today with very good components, even if they weren't invented there.
    • creshal 2y ago
      If I had a nickel for every time the RedHat ecosystem overengineered itself into a corner and decided the only possible solution was more overengineering, I could probably buy IBM.
• pmorici 2y ago
  Does anyone have any tips for debugging EFI_STUB kernels when they fail to boot? I've run into BIOS before that I can't get EFI_STUB to work on but grub works fine and I'm not sure why or even how to go about getting any debug info since the bios/firmware is a block box. Is the only option to get in touch for the motherboard vendor and how they care to look into it? It's rare but happens.
• mmphosis 2y ago
  A removable physical key: a programmable ROM. 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, ...
  • katzenversteher 2y ago
    Please elaborate. What kind of key are you using? What are you booting? On which architecture / machine?
    • mmphosis 2y ago
      > What kind of key are you using? I want this because right now I use camera cards to boot. The key needs to be wired directly to the processor and be the first and only entry point. Instantaneous boot is what I want, not resuming from hibernation but "instant on" of the full system. > What are you booting? I am booting Linux, BSD, custom systems, lightweight bootstrap programs that do a specific task like diagnostics. > On which architecture / machine? Agnostic / various. For instance, instantaneously booting / running only on GPU(s).
• gorgoiler 2y ago
  It’s a pity we aren’t really there yet with boot loading. In 2024 if I install an OS it places a boot loader in my EFI System Partition but in a way that still feels only partially complete. 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/ 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.
  • juped 2y ago
    refind will scan all your partitions for EFI bootable things; if you have two ext4 partitions each with a Debian on them, and each has a Linux kernel in /boot, it'll locate them both and you can boot either. Which sounds like what you want.
  • pabs3 2y ago
    Theres the removable media path: https://wiki.debian.org/UEFI#Booting_from_removable_media https://wiki.debian.org/UEFI#Booting_from_removable_media https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_...
  • iam-TJ 2y ago
    A small side-note to solve your "unique [EFI-SP] directory to that OS instance": 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
  • 2y ago
• egberts1 2y ago
  I prefer my bootloader (be that it may, GRUB, lilo, or even BusyBox) because thosr image will go away once the kernel is started. 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.
  • TheDong 2y ago
    Can you explain more what security vector you're talking about here, because I just don't see it? 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?
    • egberts1 2y ago
      It is the same security abstraction where you don’t allow support for network socket in process ID 1. (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.
      • TheDong 2y ago
        Sorry, I still don't follow. > 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.
• userbinator 2y ago
  Does anyone still remember when you could just dd the Linux kernel to a floppy and it would be its own bootloader? https://yosemitefoothills.com/LinuxBoot/BD-1Disk.htm https://yosemitefoothills.com/LinuxBoot/BD-1Disk.htm Here's some more documentation on this: https://www.kernel.org/doc/Documentation/x86/boot.txt https://www.kernel.org/doc/Documentation/x86/boot.txt What's old is new again... except 100x more complex and likely more than necessary.
  • lproven 2y ago
    That is exactly what I thought of when I read this post, yes.
  • Thoreandan 2y ago
    Just checked and amusingly I'd forgotten that boot/root predated LILO, I must've first seen LILO when I installed Softlanding Linux. Since I didn't have any networking on my home machine, Linux was basically a "Look, run GCC on your home machine!" option for '91 that didn't involve going through DJGPP's DOS port.
• retrochameleon 2y ago
  I use zfsbootmenu. It allows me to boot multiple OSes from different data sets, make and rollback snapshots, and even directly boot from a snapshot. It also has a minimal shell for zfs tasks.
• bfung 2y ago
  Yo Dawg, I herd you like bootloaders, so I put a bootloader in your kernel so you can boot w/a kernel while you boot a kernel.
• mixmastamyk 2y ago
  I recently moved to sdboot and prefer its simplicity compared to grub. However they still missed the mark a bit, its folder tree on the ESP is a mess. I’ll look into this but prefer kernels managed automatically by apt/dnf etc.
  • creshal 2y ago
    sd-boot on Debian 12+ is mostly self-configuring, and the folder structure is just one folder? Not sure what's messy about that.
    • mixmastamyk 2y ago
      On fedora it is 10+. Do a tree command on the efi partition.
      • creshal 2y ago
        Fedora and other Redhat-related distributions are an exercise in masochism regardless of the bootloader choice.
  • lproven 2y ago
    You are not clear; by "sdboot" do you mean systemd-boot? The abbreviation is ambiguous. There are other bootloaders called "sdboot" such as this one: https://sourceforge.net/projects/sdboot/ https://sourceforge.net/projects/sdboot/ And this one: https://www.reddit.com/r/WiiHacks/comments/glx4dt/sdboot_everything_there_is_to_know/ https://www.reddit.com/r/WiiHacks/comments/glx4dt/sdboot_eve... Please try to avoid ambiguous abbreviations. If you do mean systemd-boot you only saved 5 letters and could mean at least 3 different tools, or maybe more.
    • mixmastamyk 2y ago
      Yes, sorry when installing in fedora you have to pass the string sdboot to the kernel at boot. Still kinda experimental.
• eqvinox 2y ago
  relevant comments from Hector Martin over on Mastodon at https://social.treehouse.systems/@marcan/112754303893998372 https://social.treehouse.systems/@marcan/112754303893998372 > 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.
  • TimGhost 2y ago
    Sounds like Apple sorted itself out by themselves, while suffering from the limitation. So the correct response to this concern is "Okay. And? Apple will just sort itself out for themselves". I mean, what else can anyone do? Nothing because "but Apple?"
    • eqvinox 2y ago
      This discussion is about how to boot Linux, not how Apple's OSes do things on their devices. Booting Linux on a Macbook is the affected scenario.
• ale42 2y ago
  See also this project: https://github.com/zhovner/OneFileLinux https://github.com/zhovner/OneFileLinux Not a bootloader, but a single-file, very light Linux image that can be loaded directly as an .EFI file. Not useful as an actual OS for daily use, but can have specialized uses (I used it to network boot a whole room of PCs to a Linux showing a slideshow on the framebuffer).
  • ale42 2y ago
    See also https://news.ycombinator.com/item?id=40914761 https://news.ycombinator.com/item?id=40914761, just posted on HN. Website of the project: https://hub.zhovner.com/geek/one-file-linux/ https://hub.zhovner.com/geek/one-file-linux/
• account42 2y ago
  I haven't used GRUB since my first EFI system. The EFI itself is already a bootloader after all, why would you need another one, especially one as bloated as the new GRUB.
  • itvision 2y ago
    To pass kernel parameters? How would you do that without a bootloader?
    • account42 2y ago
      EFI can pass kernel parameters just fine, both in the default boot entries or when running the kernel from the EFI shell.
      • itvision 2y ago
        What about doing that once without using e.g. efibootmgr?
        • qhwudbebd 2y ago
          You can just pass the custom command line as you run the kernel from UEFI shell prompt, e.g. fs0:linux.efi root=/dev/nvme0n1p1 initrd=ramfs.img loglevel=2 In my experience the nuisance part is creating and editing boot entries, especially if you try to set them up from the UEFI shell, so I tend to compile any initramfs and the default kernel command line into my kernel so I can drop it at /boot/efi/boot/bootx64.efi and minimise contact with the UEFI monstrosity.
• itvision 2y ago
  Is the motherboard's NVRAM supposed to be written to so often? I'm not sure about that.
  • eqvinox 2y ago
    It originally used to be actual RAM with a battery backup. These days it's generally NOR flash (because it's small enough for savings from using NAND to not apply, and the complexity of NAND instead raising the cost). NOR has quite high write cycle tolerance/limits.
• akagusu 2y ago
  https://docs.zfsbootmenu.org/en/v2.3.x/ https://docs.zfsbootmenu.org/en/v2.3.x/
• nicman23 2y ago
  you do not use grub for being fast. you use it for when things go wrong
• conaclos 2y ago
  I use EFISTUB [1] to directly load the Linux kernel. How is nmbl different? [1] https://wiki.archlinux.org/title/EFISTUB https://wiki.archlinux.org/title/EFISTUB
• 1oooqooq 2y ago
  I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [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/195499d1531424111t-windows-admin-center-centrally-manage-all-your-windows-10-pcs-image.png 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)
  • 1oooqooq 2y ago
    I should say *the joint RH/Microsoft/et al wider push for PKCS11/TPM2/FIDO2 stuff
  • deleted 2y ago
    [deleted]
  • rini17 2y ago
    EFI stub is an existing kernel feature, not related to systemd-boot. Of course, everything can be wired together with systemd.
    • 1oooqooq 2y ago
      but it doesn't cover any of the unmentionable features that are so bad on grub. they will either be implemented in the kennel or the stub, because well, people will need dual boot, weird crypto, etc. exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?
• darby_nine 2y ago
  > Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain The same is true of the kernel. Perhaps redhat should abandon linux and commit to grub, which has the potential to boot an even more interesting or useful kernel.
• nottorp 2y ago
  If I look and think that this is another move by redhat to replace a simple independently developed solution with one that's complex enough to require a red hat issued certification, am I paranoid? Actually wait. They at least haven't proposed to replace grub with systemd. Or is that buried in one corner of the presentation?
  • mpldr 2y ago
    UKI isn't by redhat but by the Kernel devs, iirc. No redhead certs required. If you want to run with secureboot, you can use your own certs, but you can also just skip SB.
    • nottorp 2y ago
      Not certificates, certification ? As in Red Hat Valued Engineer or whatever they sell.
• qhwudbebd 2y ago
  A slight tangent, but still kind of relevant: given that we're lumbered with UEFI on x86-64, are there any active projects working on a better UEFI shell? 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?
• WesolyKubeczek 2y ago
  This sounds awfully like macOS on Apple Silicon, where the "boot menu" is in fact more or less full-fat macOS with special fullscreen GUI.
• wvh 2y ago
  I've been using `systemd-boot` for many years, which comes with the system. It's a bit simpler than Grub and LILO (team 90s, represent!). Most BIOSes have variable support for booting random images, but last time I got a new system, it was confusing to use and a bit of hit-and-miss.
• techwiz137 2y ago
  How about people moving away from 16-bit real mode(obviously a change is needed in the CPUs), removing that A20 line forgotten from history patch and actually booting like we are supposed to?
• wkat4242 2y ago
  I use whatever i want :P that's the nice thing about FOSS. I'll move on to the new cool hipster thing when I feel like it and if I see value in it.. Though generally I prefer the approach of "extend what we have with new features" over "rip out all out and start from scratch" so I spend my time mostly with the BSDs which don't jump full steam ahead into the whatever's the new thing. Even though something like systemd is undoubtedly better in many things, I also have to wrap my head around it, see how to get at the logs, build those unit files etc. On the BSDs I don't have to bother with that and just keep working as I was and which was not broken for me. The point is, something new doesn't only have to offer a tangible benefit for me to be worth it. It has to be such a big benefit for me that it offsets the hassle of getting my head around all the new stuff and most of the new Linux inventions fail at this.
• matheusmoreira 2y ago
  This is nice. I want to see Linux replace all kinds of stuff. Especially things like bootloaders, UEFI firmware and even on-device firmware.
• ForOldHack 2y ago
  Unix and Xenix did this. Single user mode. This is just a plea to have GNU/GRUB integrated into the kernel. I think it's a very good idea. Not original, but a seriously good idea. Add some more help and documentation. Pre-sets for most of the common scenaros. Multi-mode kernals? Kernals as a service? And make no mistake, this is a compelling article.