Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

341–350 of 460 posts

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

#341

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 to edit the cmdline of the kernel to recover a system

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

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

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

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

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

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

#342

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

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.

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

#343
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?

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

#344

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?

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.

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

#345

Earlier quoted context omitted.

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

I am not certain about this, but I think that these options no longer work on UEFI machines. GRUB does not have control over what options are presented if GRUB isn't the selected bootloader. This stuff is BIOS-only.

I have this working on a UEFI system. You select your Linux drive in the UEFI configuration (so the computer always boots into GRUB) and then GRUB will boot into Linux or Windows depending on the last saved option.

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

#346

Earlier quoted context omitted.

Yes, people dual boot. Particularly people who are contemplating a move from Windows. I'd hate to see Linux take the "my way or the highway" attitude of Windows.

My experience when I had a dual boot in the late 90's was that rebooting is such an interruption that you never become fully comfortable on one of the OS. You just stick to the OS you are used to and never really do the switch. While if don't dual boot you can switch completely to another OS and only use VM or remote desktop for the handful of use cases when you aren't ready yet (and then end ip abandoning them compl…

> the late 90's was that rebooting is such an interruption that you never become fully comfortable on one of the OS

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

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

#347
post #344

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?

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.

Not certificates, certification ? As in Red Hat Valued Engineer or whatever they sell.

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

#348
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?

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

#349

Earlier quoted context omitted.

I use them in embedded systems because they allow me to mount encrypted volumes without exposing the keys.

How does that work? The keys have to be loaded from somewhere.

The keys to decrypt the kernel are in u-boot. u-boot's keys are in the low level boot loader, and the keys for that are sometimes burned in write-only fuses on the microcontroller itself. Other chips have OP-TEE or similar frameworks, and you just chain the keys all the way down to the initramfs and that data is wiped when you start init.

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

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

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

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

#350

Earlier quoted context omitted.

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 ?

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

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 ) its not too hard.

Post reply on HN