Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

111–120 of 460 posts

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

#112

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?

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)

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

#113

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

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

#115

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 quite useful. But not as a replacement for a bootloader.

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

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

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

#117

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…

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.

Grub is the same everywhere. Motherboard bios/uefi is not. It isn't F10 for me.

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

#118

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…

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.

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

#119
post #112

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?

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?

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

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

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)
Post reply on HN