No more boot loader: Please use the kernel instead • Hacker News Board

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

#411

Post by blucaz » Wed, Jul 10, 2024, 10:24 AM UTC

collinmanderson wrote: post #390

1oooqooq wrote: post #321

I will translate the doublespeak from redhat, which is similar to how they started to push systemd (really). > [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes. No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments. > Loaded by the EFI stub All the ta…

systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather tha…

> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. > Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.

This is completely wrong though - the main point of sd-boot is that it does _not_ implement any of that - no filesystems, no fonts, no themes, nothing at all, the firmware is used to do all the risky stuff via the UEFI protocols. So it is very much not reimplementing what grub or the kernel do, the exact opposite in fact, it's the number one design goal.

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

#412

Post by p_l » Wed, Jul 10, 2024, 10:29 AM UTC

lproven wrote: post #380

surajrmal wrote: post #328

Earlier quoted context omitted.

The problem with all of the alternatives is that they aren't friendly for alternative OS. They mostly operate on a fork model, so upstreaming support for an OS doesn't mean everyone using that bootloader will support your OS. You either need to pretend to be Linux with a sort of boot shim, or build and flash a custom bootloader with support, which might be non trivial if you cannot get access to the forked bootloader…

Both the suggestions I gave were designed and built to be FOSS and work with any OS. UEFI is more restrictive -- and tightly controlled by large industry vendors, not the community -- than either of them. So, no, I totally disagree on all points.

OpenFirmware is similar level of complexity as UEFI, to be quite honest, and lacks certain mechanisms that were designed into ACPI (and inherited by UEFI) precisely to support multiple different operating systems without requiring the OS to be have specialty drivers for every little bit.

Sure, in the happy path, you can depend on OpenFirmware giving you parameters like locations and addresses and "this device is compatible with X so you can use its driver", but it still requires that you have the specific driver the device is compatible with, and a new hardware release was often incompatible with older versions of OSes because, unlike ACPI, you can't encode information like "Hey, I'm compatible with interface X version Y" => "here's limited functionality because your driver is not updated for interface X version Y+1 but the computer will work".

Instead you had special "hardware support releases" to get the OS to boot at all.

CoreBoot and uboot by itself provide even less support. They might have open source, but they provide effectively closed platform to the end user. UEFI is in practice less restrictive because I only have to program to the interface, and in absence of gross bugs, I can expect things to work - whether it's a boot-time driver to support my super-duper-special storage add-in card, or a custom OS that I want to be available for normal people to try out by running on their random home PC. Hell, if Linux kernel people didn't tell they would no longer accept "platform definition" patches, you probably still wouldn't have FDT used on ARM with uboot.

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

#413

Post by p_l » Wed, Jul 10, 2024, 10:31 AM UTC

lproven wrote: post #313

notorandit wrote: post #301

Earlier quoted context omitted.

Maybe it is time to re-think the entire hardware boot process and ditch the BIOS altogether.

It probably was, but UEFI was not a good answer. I'd have preferred CoreBoot or OpenFirmware, but the PC industry was too slow to move and let Intel -- still smarting from Microsoft forcing it to adopt AMD's 64-bit x86 extensions -- take control of the firmware.

UEFI btw is late 1990s thing, with work starting because BIOS was unwieldy chimeara that didn't match anything in hardware, and supporting things like network booting by hooking into "boot BASIC program from Cassette" subroutine was problematic.

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

#414

Post by DEADMINCE » Wed, Jul 10, 2024, 11:05 AM UTC

jchw wrote: post #68

ec109685 wrote: post #52

Earlier quoted context omitted.

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.

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…

> I think Windows even does this now.

Why? What advantage is there for Windows to do this?

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

#415

Post by DEADMINCE » Wed, Jul 10, 2024, 11:07 AM UTC

ziml77 wrote: post #398

ale42 wrote: post #266

Earlier quoted context omitted.

No, it doesn't. Even a sysprepped image of Windows (which thus runs Setup to install drivers and finalize the installation) doesn't change the boot order on UEFI machines. I think just the installer does this when you first install Windows.

That's so weird. Normally I don't want my OS changing what is booted into on a whim, but going back into the same OS for cases like these just seems like sane behavior to me.

There's good reason you might not want that behavior, and no reason to enforce it. Booting an alternate OS doesn't interrupt Windows update operations.

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

#416

Post by prmoustache » Wed, Jul 10, 2024, 11:35 AM UTC

michaelmrose wrote: post #408

prmoustache wrote: post #406

Earlier quoted context omitted.

Well when you buy a desktop computer in 2024 their are usually 4 main ways: - buying a ready made computer from a brand --> always come with an integrated GPU. Some will be even such a small form factor you have to use an external thunderbolt connected GPU if you want to use one. - you build your computer yourself from parts --> you decide your motherboard and CPU, if VM passthrough is something you want to do, you j…

The average PC is already a trade of that costs the average user around $800 and near 2/3 would need a substantial RAM upgrade a new GPU or both to make gaming through VM passthrough a reality. Most people aren't looking to buy new hardware and learn new tech to game. It sounds like a useful toy for those whom already enjoy playing with their computer as much as playing with the game. That said wouldn't limiting the…

> Most people aren't looking to buy new hardware and learn new tech to game.

Most people don't play game.

Most people that play game that isn't solitary or a web game just buy a playstation, xbox or Switch.

Only a relatively small fraction of people playing AAA games use computer for that. The most hardcore one and the most willing to spend money on a game Rig. And I am pretty sure most of them aren't the least interested in dual boot because they would have a desktop gaming rig and a laptop for everything else anyway. Only a tiny fraction of gamers is probably interested in dual booting. You are part of that tiny group. Fine. The nmbl tool presented in this conference do not prevent dual booting anyway so I am not even sure why people act like they should be offended because grub might be replaced someday by something else with more capabilities.

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

#417

Post by smeg_it » Wed, Jul 10, 2024, 11:53 AM UTC

nerdponx wrote: post #55

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…

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.

I've used gummiboot before systemd ate it; and I've used rEFInd. Mainly, I just followed the excellent documentation @ https://www.rodsbooks.com/; that's also how I first familiarized myself with UEFI (Thanks Rod!).

My brain has leaked all the information I understood (unfortunately). Is rEFInd still active? Is there a gummiboot fork (besides systemd)?

Personally, I kind of hate Redhat calling itself that now, it's IBM. You can tell because all of the online knowledge from the community on their websites are now pay-walled. RIP Redhat (CentOS) (I'll miss you)

P.S. Thanks Rocky Linux (and others like it)

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

#418

Post by sqeaky » Wed, Jul 10, 2024, 2:20 PM UTC

prmoustache wrote: post #416

michaelmrose wrote: post #408

Earlier quoted context omitted.

The average PC is already a trade of that costs the average user around $800 and near 2/3 would need a substantial RAM upgrade a new GPU or both to make gaming through VM passthrough a reality. Most people aren't looking to buy new hardware and learn new tech to game. It sounds like a useful toy for those whom already enjoy playing with their computer as much as playing with the game. That said wouldn't limiting the…

> Most people aren't looking to buy new hardware and learn new tech to game. Most people don't play game. Most people that play game that isn't solitary or a web game just buy a playstation, xbox or Switch. Only a relatively small fraction of people playing AAA games use computer for that. The most hardcore one and the most willing to spend money on a game Rig. And I am pretty sure most of them aren't the least inter…

Approximately half of gaming revenue is from PC customers. It wavers up and down depending on exactly what metric you want to use and when the last console refresh was.

You are correct on the complexity cost and how most people, even those with nice gaming computers, just don't want to deal with more complexity than needed. Even mandating a store app that works causes a significant hit to conversion rates. EA couldn't give away Dead Space a previously successful AAA title when bundled with their store.

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

#419

Post by collinmanderson » Wed, Jul 10, 2024, 2:48 PM UTC

blucaz wrote: post #411

collinmanderson wrote: post #390

Earlier quoted context omitted.

systemd-boot comes up in the Q&A at 29:50. (The main problem nmbl is trying to solve is code-duplication with the kernel and therefore security issue duplication, and just like grub or any of the alternatives, systemd-boot duplicates code that's already in the kernel. The security holes will exist in any case, but the goal is to reduce security hole duplication by reusing as much of the kernel as possible, rather tha…

> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader. > Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's goo…

Ahh ok so it sounds like systemd-boot's philosophy is keeping things simple and minimal and re-using UEFI firmware as much as possible, to minimize risks with the linux kernel having issues booting, at the expense of not having as many features.

I suppose then the hope is that nmbl would basically be a general-purpose fully-featured replacement for grub, which seems to be going in the direction of being a full kernel anyway:

> one with quite some bells and whistles, with networking, complex storage, cryptography, http client, ca store and stuff (I mean, that's how I understand it, i.e. it should be able to load kernels from sources that require all that). It hence will need require regular updating (as much as the 2nd stage kernel most likely, if not more often, since it probably needs ca store built in), and quite possibly will break every now and then nonetheless, because it's basically a full OS you are boot as first stage.

- https://lwn.net/Articles/981149/

It sounds like if you don't need grub's complex features, then systemd-boot is probably the safest way to go, but if you do need grub's complex features, then nbml aims to be the safest and most reliable way to get those features.

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

#420

Post by jchw » Wed, Jul 10, 2024, 4:42 PM UTC

DEADMINCE wrote: post #414

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…

> I think Windows even does this now. Why? What advantage is there for Windows to do this?

I'm not entirely sure, to be honest. If you google something like "windows 11 advanced startup settings" you'll see what I mean, though: the boot menu is now in Windows.

I guess it allows the bootloader to be much simpler, at least in theory.