Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

Post reply on HN
Print view View original

131–140 of 460 posts

Re: No more boot loader: Please use the kernel instead

#131

Post by dataflow »

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...?

Re: No more boot loader: Please use the kernel instead

#132

Post by garaetjjte »

yjftsjthsd-h wrote: post #95
alerighi wrote: post #45

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, yo…

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.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

Re: No more boot loader: Please use the kernel instead

#133

Post by rodgerd »

josephcsible wrote: post #119
mjg59 wrote: post #112

Earlier quoted context omitted.

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…

Isn't everything that GRUB reads only writable by root? Is the threat model that root is the attacker?

root is not necessarily the owner of the system.

Re: No more boot loader: Please use the kernel instead

#134

Post by mjg59 »

vlovich123 wrote: post #128
mjg59 wrote: post #107

Earlier quoted context omitted.

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.

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.

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.

Re: No more boot loader: Please use the kernel instead

#135

Post by TylerE »

garaetjjte wrote: post #132
yjftsjthsd-h wrote: post #95

Earlier quoted context omitted.

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.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

Theoretically, couldn't it just write to a "boot this image next time" field (is the legacy MBR area available?) and trigger a reboot?

Re: No more boot loader: Please use the kernel instead

#136

Post by yjftsjthsd-h »

garaetjjte wrote: post #132
yjftsjthsd-h wrote: post #95

Earlier quoted context omitted.

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.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

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).

Re: No more boot loader: Please use the kernel instead

#137

Post by 29athrowaway »

alerighi wrote: post #45

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, yo…

I need a bootloader that automatically deletes Windows partitions upon detection.

And is also themed like XBill.

Re: No more boot loader: Please use the kernel instead

#138

Post by sholladay »

1vuio0pswjnm7 wrote: post #115
alerighi wrote: post #45

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, yo…

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…

> 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)?

Re: No more boot loader: Please use the kernel instead

#139

Post by derefr »

garaetjjte wrote: post #132
yjftsjthsd-h wrote: post #95

Earlier quoted context omitted.

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.

It could kexec other kernels but probably won't be able to jump to other OS bootloaders after it already called ExitBootServices.

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.")

Re: No more boot loader: Please use the kernel instead

#140

Post by jchw »

bityard wrote: post #108
jchw wrote: post #68

Earlier quoted context omitted.

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 inter…

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 Sy…

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.

Post reply on HN