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

251–260 of 460 posts

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

#251

Post by FeepingCreature »

kbolino wrote: post #81
drewg123 wrote: post #74

Earlier quoted context omitted.

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.

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…

You could probably build a "virtual initramfs":

- linux tells the bootloader what folder the modules live

- bootloader just puts them all in memory

- linux just picks what it needs.

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

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

#252

Post by herewulf »

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…

It allows you to enter your passphrase to unlock your Linux LUKS partition before you even get a menu to chainload Windows.

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

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

#253

Post by TheDong »

egberts1 wrote: post #247
TheDong wrote: post #233

Earlier quoted context omitted.

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

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

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.

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

#254

Post by drewdevault »

garaetjjte wrote: post #148
derefr wrote: post #139

Earlier quoted context omitted.

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

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

Something that hasn't been addressed by comments here yet is that you could implement EFI boot services in the Linux kernel and essentially turn Linux into a firmware interface. Though note that I generally shy away from any attempts to make the kernel into a really fat bootloader.

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

#255

Post by juped »

gorgoiler wrote: post #225

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

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.

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

#256

Post by p_l »

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

Earlier quoted context omitted.

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

You can set BootNext variable to number of BootXXX variable you want to use once for next boot.

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

#257

Post by 1vuio0pswjnm7 »

cool_beanz wrote: post #237
1vuio0pswjnm7 wrote: post #115

Earlier quoted context omitted.

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. Yes it does, I use it with two kernels, just have different entry for each stub in UEFI. Whenever I want to boot the non-default kernel I just hit F11 (for BIOS boot menu, on my motherboard) and choose the boot option. You just need to add the boot options in UEFI, pointing to the corresponding EFI files. They also have the ke…

Thank you.

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

#258

Post by egberts1 »

TheDong wrote: post #253
egberts1 wrote: post #247

Earlier quoted context omitted.

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

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

/boot should never be mounted.

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

#259

Post by kasabali »

mjg59 wrote: post #116

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.

> completely useless if you care about Measured Boot

I stopped reading there. All these engineers who help build and defend this draconian crap should be forced to used only an iPad for the rest of their lives.

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

#260

Post by eqvinox »

relevant comments from Hector Martin over on Mastodon at 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.

Post reply on HN