[HN Gopher] No more boot loader: Please use the kernel instead
___________________________________________________________________
No more boot loader: Please use the kernel instead
Author : zdw
Score : 291 points
Date : 2024-07-08 18:27 UTC (4 hours ago)
(HTM) web link (pretalx.com)
(TXT) w3m dump (pretalx.com)
| drewg123 wrote:
| 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).
| ta8645 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| medstrom wrote:
| You're talking about something like ZFS, and I get that
| they can't just compile it in, but a distro can still
| ship the module, if I'm not mistaken.
|
| ...But to load it at boot time it absolutely must be done
| through an initramfs. Is that right?
| aaronmdjones wrote:
| > But to load it at boot time it absolutely must be done
| through an initramfs. Is that right?
|
| 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.
| megous wrote:
| It doesn't have to be a module if you're building the
| kernel for yourself. No violation in that.
| aaronmdjones wrote:
| GP was talking about distribution kernels.
| linsomniac wrote:
| Is anyone really wanting to get back into the business of
| building their own kernels? I started using Linux heavily in
| '92, and I've built a lot of kernels, and am quite happy to
| not be building them anymore.
| ssl-3 wrote:
| I kind of liked compiling my own kernels. I felt I was
| better-connected to the state of things, and it was fun to
| see it all evolve from the vantage point of "make
| menuconfig".
|
| But initramfs isn't so bad, and it allows things like ZFS
| root to have a modicum of smoothness and integration.
| megous wrote:
| It's easy (2-3 commands), takes like a minute on a modern
| machine with trimmed down kernel configuration, and you can
| customize the kernel to your liking (write/patch drivers,
| embed firmware blobs, fix things that are broken or
| missing). What's to hate? :)
|
| 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.
| arp242 wrote:
| What's the reason it doesn't load those modules from the
| regular filesystem? That's what FreeBSD does, and seems to
| work well enough?
| ta8645 wrote:
| Because there are a lot of different types of filesystems
| supported. And you'd have to compile them all into the
| kernel. Which of course you can do, that is supported by
| the build system today. But Distros typically prefer to
| keep their kernels small, and not waste the RAM that would
| be taken up by compiling it all into the kernel.
| Aurornis wrote:
| > I'd rather have "NMIRFS" (no more initramfs).
|
| In many cases, you don't need initramfs. I rarely use one in
| embedded systems.
| fullstop wrote:
| I use them in embedded systems because they allow me to mount
| encrypted volumes without exposing the keys.
| Arnavion wrote:
| Linux has multiple choices for filesystems for root, even if
| you only count the most popular ones. And on top of that they
| could be encrypted by LUKS. Duplicating all that into the
| bootloader is what GRUB does, and poorly. Putting the kernel
| into the ESP is much better in that regard.
| m463 wrote:
| > I personally think they're moving in the wrong direction
|
| the other direction is to put everything in systemd. :)
| aaronmdjones wrote:
| As other sibling comments have explained, an initramfs is
| usually optional for booting Linux.
|
| 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.
| mlyle wrote:
| Yes, I think he realizes it's optional for booting Linux.
|
| 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.
| zdw wrote:
| FWIW, Grub has a read-only ZFS implementation to allow booting:
| https://git.savannah.gnu.org/cgit/grub.git/tree/include/grub...
| nubinetwork wrote:
| Grub uses an ancient version of zfs code, it's tied to
| Oracle's zfs and they refuse to update it to current openzfs.
| UnlockedSecrets wrote:
| Are there any instances of features being utilized that the
| old version of the code is unable to cope with well enough
| to be able to boot the system?
| upon_drumhead wrote:
| Native ZFS encryption is the major one I'm aware of
| nubinetwork wrote:
| https://github.com/openzfs/zfs/tree/master/cmd/zpool/comp
| ati...
| yjftsjthsd-h wrote:
| Refuse, or legally can't? Oracle doesn't own the copyrights
| on commits made after illumos forked from the corpse of
| opensolaris.
| dizhn wrote:
| Yeah update your zfs file system to gain new features and
| bam, you can't boot no more.
| mjg59 wrote:
| This requires a bunch of additional logic in the bootloader
| (eg, providing disk encryption keys), and since you're not
| doing this in a fully-featured OS environment (as you are in
| the initramfs case) it's going to be hard providing a
| consistent experience through the entire boot process. Having
| the pre-boot environment be a (slightly) cut-down version of
| the actual OS means all your tooling can be shared between the
| two environments.
| sim7c00 wrote:
| 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.
| zauguin wrote:
| This is a step in that direction. What they are proposing is
| not so much "no bootloader" but using a small Linux as
| bootloader. I'm using a similar setup for some time and it
| gives some of these advantages. Especially you get support for
| all relevant filesystems (you can support everything Linux
| supports because it _is_ Linux), it can dynamically build a
| minimal initramfs with only the needed drivers if you want to
| and understands module dependencies (e.g. it can just dump the
| list of modules it uses itself) and is generally much more
| flexible.
| rcxdude wrote:
| Does FreeBSD's loader share code with the kernel? It does seem
| like a lot of duplication of systems to make it work in
| comparison to just using the same code.
| fooker wrote:
| The more smartness you put here, the more it makes life
| difficult for non-standard operating systems.
|
| And if this bit is closed source, and something doesn't work,
| you don't have a recourse.
| the_panopticon wrote:
| Seems to be a trend including work like
| https://www.linuxboot.org/.
| theteapot wrote:
| Isn't one of the use cases in GRUB choosing which kernel you want
| to load?
| SahAssar wrote:
| Via EFI probably.
| m463 wrote:
| Does that mean the UI you will use to choose the kernel will
| probably be the bios?
| Arnavion wrote:
| 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 wrote:
| 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 wrote:
| They address this use case in the video. Their loader can show
| a menu.
| devit wrote:
| 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 wrote:
| 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 wrote:
| 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...
|
| 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 wrote:
| Ah, so another Stratis then.
| saghm wrote:
| 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 wrote:
| >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.
| benwaffle wrote:
| >To be clear, systemd-boot doesn't replace GRUB, in that
| systemd-boot can only boot other EFI binaries, so it still
| requires the kernel to be compiled as a UKI. A GRUB setup
| with a regular vmlinuz + separate initramfs in root
| partition (or boot partition that's not the ESP) can't be
| replaced with systemd-boot directly. You first need to
| switch to a UKI-in-ESP setup.
|
| That's wrong, my laptop right now uses systemd-boot with a
| vmlinuz and an initramfs, no UKI. See a configuration
| example here: https://wiki.archlinux.org/title/Systemd-
| boot#Adding_loaders
| Arnavion wrote:
| Ah yes, I've used it with the default auto-detected UKIs
| for so long that I forgot about the explicit loader
| entries config.
| saghm wrote:
| > 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.
|
| I think my confusion here is that calling something
| "systemd-" because it's part of the group called systemd is
| tautological; anything that's independent could just as
| easily not be included in that group and not be called
| that. `nmbl` sounds like a piece of "core OS software", so
| why couldn't it be included in that group as well? It
| almost sounds like the only reason not to is to avoid
| naming confusion between multiple things in the "systemd
| group of software" that are boot-related, and that seems
| kind of silly.
|
| To be clear, I'm not taking a pro- or anti-systemd in this
| thread; my concerns come from a place of pedantry around
| naming rather than anything technical. It just feels weird
| to me that the name "systemd-boot" could plausibly have
| been applied to either the bootloader or the "no-more-
| bootloader" if the other didn't exist, and I wish that
| things were named in a way that actually conveys using
| information rather than arbitrarily attaching confusing
| branding.
| andrewstuart wrote:
| 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 wrote:
| 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 wrote:
| It's not that it defeated you, it's literally undocumented what
| you're supposed to do.
| bradley13 wrote:
| 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.
| benwaffle wrote:
| 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.
| ars wrote:
| The simplest is LILO without an initrd
| rcxdude wrote:
| Honestly I'm surprised grub is still going post-UEFI. It's now
| pretty much entirely unnecessary. Your simplest path is
| probably UEFI-stub, where there is extra bootloader, just your
| BIOS loads the kernel. The main disadvantage is this is subject
| to the whims of your hardware manufacturer to implement it in a
| usable manner. If you want a nicer menu then systemd-boot is
| your next simplest option (despite the name, it is actually
| more or less seperate from systemd apart from maintenance and
| systemd having some integration with it).
| linuxrebe1 wrote:
| 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 wrote:
| You can switch OS's using the UEFI menu instead. It's not
| always convenient, depending on your UEFI implementation,
| however.
| ack_complete wrote:
| 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 wrote:
| I'm not sure I experienced the same with the Windows boot
| loader so maybe that behavior was something case specific
| instead of intended?
| Shorel wrote:
| 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 wrote:
| 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 wrote:
| 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.
| fsniper wrote:
| 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 wrote:
| 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 wrote:
| I nearly did systemd-boot last install but grub2 behaves
| better if the motherboard is upgraded/otherwise factory reset
| so I shied away.
| Arnavion wrote:
| systemd-boot can be compiled and used independently of the
| booted OS using systemd. It also started out as gummiboot,
| unrelated to systemd.
| andrewmcwatters wrote:
| 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/...
| rcxdude wrote:
| 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".
| yjftsjthsd-h wrote:
| 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.
| samsartor wrote:
| 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
| jmb99 wrote:
| > 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.
| 201984 wrote:
| 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_ wrote:
| I do the same. The only advantage I can think of is editing
| kernel boot option on boot.
| pzmarzly wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mjg59 wrote:
| UKIs provide mechanisms for adding additional sidecar modules
| which can extend the initramfs, provide additional command line
| modifications, and so on.
| Delk wrote:
| Entering the BIOS menu takes several seconds on my ThinkPad,
| and getting to the EFI boot menu from there takes a few more.
| That's after hitting the key during the correct time during the
| boot process, which sometimes takes guessing.
|
| 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.
| lofaszvanitt wrote:
| Also create a boot please that rivals w10's almost instant boot
| process. I just hate the current slow/non parallel boot process.
| bayindirh wrote:
| 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.
| Animats wrote:
| 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 wrote:
| QNX still works that way. It's just no longer free.
| Animats wrote:
| And the desktop environment is gone.
| alerighi wrote:
| 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.
| ec109685 wrote:
| 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 wrote:
| 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...
| bityard wrote:
| Let's say I have a dual-boot system with two totally
| independent OSes, Systems A and B. It is powered down. I
| want to boot into System B but the EFI is configured to
| boot into System A by default.
|
| 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.
| superb_dev wrote:
| Presumably nmbl would show you a menu to select the which
| OS start if you're dual booting. You wouldn't have to
| manually set some UEFI variable
| jchw wrote:
| Sort of, except it's automated.
|
| 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.
| derefr wrote:
| > instead of immediately loading the System A userland
|
| 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.
| jchw wrote:
| Yes of course. I really mean to say, before/instead of
| pivoting to the OS root. It sounds like this will
| synergize well with the UKI effort too, at least from a
| Secure Boot perspective.
| nerdponx wrote:
| rEFInd is the magic tool here.
|
| Personally I still use GRUB for all of the reasons you stated
| above. But rEFInd + kernel gets you pretty close.
| throwway120385 wrote:
| If you embed an x86 system somewhere then you might find
| yourself not wanting to use GRUB because you don't want to
| display any boot options anywhere other than the Linux kernel.
| The EFI stub is really handy for this use case. And on
| platforms where UBoot is common UBoot supports EFI which makes
| GRUB superfluous in those cases.
|
| 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.
| Sesse__ wrote:
| I must admit that on U-Boot platforms, I use U-Boot EFI to
| load grub-efi, so that I can have a non-terrible
| bootloader...
| Denvercoder9 wrote:
| What kind of machines are people using that entering the UEFI
| boot menu is difficult? On all three of mine I just press F10
| during the first 5 or seconds the vendor logo shows, and I end
| up in a nice menu where I could select Windows, other kernels,
| memtest, or the EFI shell or setup.
| mjg59 wrote:
| One easy way to meet Microsoft's boot time requirements is to
| skip input device enumeration, so there's a lot of machines
| meeting the Windows sticker requirements where entering the
| firmware either requires a bunch of failed boots or getting
| far enough into the boot process that you can be offered an
| opportunity to reboot into the setup menu.
| Denvercoder9 wrote:
| Huh, today I learned. I'll consider myself lucky I didn't
| come across one of these machines yet.
| Sakos wrote:
| I've encountered way too many of these and I hate them
| with all my being.
| Dwedit wrote:
| I have a system where you need to _hold down power_ when
| turning on the PC to get out of "Quick Boot" mode, and get
| the ability to get to the bios screen. It's a Sandy-Bridge-
| era Intel motherboard.
| pavon wrote:
| I was working on my Dad's Dell laptop this weekend, and no
| matter how quickly I spammed the correct key (F12 in this
| case) it would miss it and continue to a full boot about 3/4
| times. I never figured out if it is just picky about timing,
| or if it had different types of reboots where some of them
| entering BIOS wasn't even an option.
| wongarsu wrote:
| Newer Dell laptops have a BIOS option to artificially delay
| the boot process by a configurable number of seconds to
| give you more time to enter the menu. Which should be proof
| enough that the default time window is an issue.
| LH9000 wrote:
| I start tapping as soon as the screen blanks, probably
| twice a second. I find this to be best for all BIOS/UEFI
| interfaces.
| spockz wrote:
| On my last two uefi boards, if I press F12 or F8 too soon
| after power on it either stalls the boot, or it makes it
| restart. When the latter happens, I'm always too careful in
| pressing it causing me to miss the window of opportunity and
| booting right to the OS. Entering the bios or choosing the
| boot drive regularly takes me 3 tries. (Gigabyte with Intel
| and Asus with AMD.)
| Am4TIfIsER0ppos wrote:
| Grub is the same everywhere. Motherboard bios/uefi is not. It
| isn't F10 for me.
| yjftsjthsd-h wrote:
| If I'm understanding correctly, it might help to point out that
| in spite of the title they _are_ proposing a bootloader, which
| can still let you modify the cmdline, boot to other OSs, etc.
| It 's just that the bootloader is itself using the Linux kernel
| so it can do things like read all Linux filesystems for "free"
| without having to rewrite filesystem drivers.
| garaetjjte wrote:
| It could kexec other kernels but probably won't be able to
| jump to other OS bootloaders after it already called
| ExitBootServices.
| TylerE wrote:
| Theoretically, couldn't it just write to a "boot this image
| next time" field (is the legacy MBR area available?) and
| trigger a reboot?
| adtac wrote:
| The target image would need to reset that field so that a
| second reboot puts you back into the bootloader because
| otherwise you'll be stuck booting that image forever.
| garaetjjte wrote:
| Well you could change default boot entry in efivars, but
| if you're relying on firmware for that why not use
| firmware provided boot menu anyway?
| yjftsjthsd-h wrote:
| This is being discussed more extensively in other comment
| threads but it sounds like maybe there's a way for it to
| just reboot but set a flag so the firmware boots into a
| different .efi next time (once).
| derefr wrote:
| The sibling comments who think you need to jump back to EFI
| to solve this, are thinking in layer-ossified terms. This
| is Redhat proposing this, and they're perfectly confident
| in upstreaming kernel patches to make this happen.
|
| 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.")
| garaetjjte wrote:
| >and if decides that it is, then it never calls
| ExitBootServices
|
| 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.
| kragen wrote:
| you seem to be saying that they are using two separate
| kernels, one for the bootloader and one for the final boot
| target
|
| 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
| zozbot234 wrote:
| > - 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
|
| You can use the UEFI shell for this. It's kind of a replacement
| for the old MS-DOG command line.
| Dalewyn wrote:
| >it allows to dual-boot with Windows easily
|
| 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.
| 1vuio0pswjnm7 wrote:
| As much as I generally detest indirection, for me a bootloader
| is a necessity; I need the flexibity to boot different OS
| kernels. AFAIK, UEFI offers no such flexibility. NetBSD's
| bootloader is best for me. UEFI seems like an OS unto itself. A
| command line, some utilties and network connectivity (UNIX-like
| textmode environment) is, with few exceptions, 100% of what I
| need from a computer. To me, UEFI seems potentially quite
| useful. But not as a replacement for a bootloader.
| sholladay wrote:
| > I need the flexibity to boot different OS kernels. AFAIK,
| UEFI offers no such flexibility.
|
| Isn't this how Apple's Bootcamp works (at least on Intel
| based Macs)?
| ziml77 wrote:
| Does Windows not ensure that the UEFI boots back into Windows
| when it does an auto-reboot for updates? There's a UEFI
| variable called BootNext which Windows already knows how to use
| since the advanced startup options must be setting it to allow
| rebooting directly to the UEFI settings.
|
| 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.
| joe5150 wrote:
| Not in my experience. For my typical dual boot situation
| where Grub is installed as the bootloader, I have to update
| the Grub settings like so to allow Windows updates to go
| smoothly: GRUB_DEFAULT=saved
| GRUB_SAVEDEFAULT=true
| 29athrowaway wrote:
| I need a bootloader that automatically deletes Windows
| partitions upon detection.
| radium3d wrote:
| I dual boot Win/Arch easily with EFISTUB setup. It's super
| quick to boot to a usb stick of arch if I need to edit anything
| with the configuration in an "emergency" situation as well.
| https://wiki.archlinux.org/title/EFISTUB
| bastien2 wrote:
| 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 wrote:
| Isn't their argument that much of this code already exists in
| Linux?
| mjg59 wrote:
| 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 wrote:
| 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?"
| michaelt wrote:
| 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 wrote:
| 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 wrote:
| 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
| peter_d_sherman wrote:
| >"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 wrote:
| 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 wrote:
| 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/Right_to_repair
|
| https://en.wikipedia.org/wiki/Non-volatile_memory
|
| https://libreboot.org/
|
| https://www.coreboot.org/
|
| https://en.wikipedia.org/wiki/Open-source_firmware
| mjg59 wrote:
| UEFI didn't exist at all on older systems, so instead you
| had BIOS which provided no security assertions whatsoever
| and exposed an even larger runtime attack surface (UEFI at
| least as the boottime/runtime distinction, and after
| ExitBootServices() most of the firmware code is discarded -
| BIOS has no such distinction and the entire real-mode
| interface remains accessible at runtime).
|
| In terms of how modifiable UEFI is - this is what Boot
| Guard (Intel) and Platform Secure Boot (AMD) are intended
| to deal with. They both support verifying that the firmware
| is correctly signed with a vendor-owned key, which means
| it's not possible for an attacker to simply replace that
| code (at the obvious cost of also restricting the user from
| being able to replace it - I don't think this is a good
| tradeoff for most users, but it's easy to understand why
| the feature exists).
|
| If you want to be able to fully verify the trustworthiness
| of a system by having full source access then you're going
| to either be constrained to much older x86 (cases where
| Coreboot can do full hardware init without relying on a
| blob from the CPU vendor, ie anything supported by
| Libreboot) or a more expensive but open platform (eg, the
| Talos boards from Raptor). If you do that then you can
| build this entire chain of trust using keys that you
| control, and transitively anyone who trusts you can also
| trust that system.
|
| But there's no benefit in replacing all of the underlying
| infrastructure with code you trust if it's then used to
| boot something that can relatively easily be tricked into
| executing attacker-controlled code, which is why projects
| like this are attempting to replace components that have a
| large attack surface and a relatively poor security track
| record.
| vlovich123 wrote:
| 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
| mjg59 wrote:
| 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 wrote:
| 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.
| mjg59 wrote:
| My broader point is that the majority of kexec issues are
| associated with the difficulty in quiescing the hardware,
| and there's simply no need to load the majority of drivers
| before offering this option which constrains the problem
| significantly.
| vlovich123 wrote:
| Does the kernel actually support doing that? The pitch is
| that they already have all the pieces and don't need to
| do any kernel work to enable this.
| mjg59 wrote:
| Module loading is handled by udev, so udev merely needs
| to support enumerating a subset of the hardware to (eg)
| ensure input devices are available.
| vlovich123 wrote:
| Again, I think you're thinking I'm saying which I'm not.
| I'm not saying it's impossible. I'm suggesting the scope
| of work may be harder than they pitched which is that
| they have all the pieces and don't really need to do much
| other than some packaging & some EFI integration. UDEV
| changes and kernel patches (more than the trivial 2 they
| have right now) would prove that the idea requires more
| work than anticipated.
| mjg59 wrote:
| I don't see any need for kernel patches, and the udev
| policy is just config rather than code as far as I can
| tell. Bringing kexec into this is certainly more
| complicated than not using kexec, but I wouldn't expect
| (and I do have some familiarity of working with kexec)
| this to be a lot of engineering work.
| kbolino wrote:
| This is true on "IBM compatible" x86 PCs and will continue to
| be for the foreseeable future, but it's not the case on all
| platforms. Some of them require graphics drivers to show
| anything at all, even simple text.
| AtlasBarfed wrote:
| Another red hat "improvement" that causes another decade plus of
| churn and documentation and support chaos?
| unixhero wrote:
| Awesome, finally.
| Aissen wrote:
| 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 wrote:
| 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 wrote:
| 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) 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 wrote:
| 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.
| josephcsible wrote:
| 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 wrote:
| 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 wrote:
| Isn't everything that GRUB reads only writable by root? Is
| the threat model that root is the attacker?
| mjg59 wrote:
| 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)
| rodgerd wrote:
| root is not necessarily the owner of the system.
| lern_too_spel wrote:
| Or potentially by another user loading that partition if
| you boot into another OS.
| pmarreck wrote:
| No thanks. NixOS lets you pick the generation at boot via GRUB.
| This is extremely useful.
| mjg59 wrote:
| 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/ and I think that's a much more
| interesting set of concerns.
| DEADMINCE wrote:
| 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.
| dataflow wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| kevinoid wrote:
| This approach sounds similar to Petitboot
| <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>.
| hackernudes wrote:
| 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
| hackernudes wrote:
| 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 but the answer
| isn't clear to me - "setting FE variables". Is that frontend?
| firmware environment?
| JoeAltmaier wrote:
| 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.
| CodeWriter23 wrote:
| 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)
___________________________________________________________________
(page generated 2024-07-08 23:00 UTC)