Live data from Hacker News

No more boot loader: Please use the kernel instead

pretalx.com

381–390 of 460 posts

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

#381

Earlier quoted context omitted.

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

I mean, you can and you can't.

AFAIK, the UEFI spec imposes no requirement that (non-hotplug) devices be re-initializable after you've already initialized them once. Devices are free to take the "ExitBootServices has been called" signal from EFI and use it to latch a mask over their ACPI initialization endpoints, and then depend on the device's physical reset line going low to unmask these (as the device would start off in this unmasked state on first power-on.)

Devices are also free to have an "EFI-app support mode" they enter on power-on, and which they can't enter again once they are told to leave that mode (except by being physically reset.) For example, a USB controller's PS2 legacy keyboard emulation, or a modern GPU's VGA emulation, could both be one-way transitions like this, as only EFI apps (like BIOS setup programs) use these modes any more.

Of course, presuming we're talking about a device that exists on a bus that was designed to support hotplug, the ability to "logically" power the device off and on — essentially, a software-controlled reset line — is part of the abstraction, something the OS kernel necessarily has access to. So devices on such busses can be put back in whatever their power-on state is quite easily.

But for non-hotplug busses (e.g. the bus between the CPU to DRAM), bringing the bus's reset line low is something that the board itself can do; and something that the CPU can do in "System Management Mode", using special board-specific knowledge burned into the board's EFI firmware (which is how EFI bring-up and EFI ResetSystem manage to do it); but which the OS kernel has no access to.

So while a Linux kernel could in theory call ExitBootServices and then virtualize the API of EFI boot services, the kernel wouldn't be guaranteed to be able to actually do what EFI boot services does, in terms of getting the hardware back into its on-boot EFI-support state.

The kernel could emulate these states, by having its native drivers for these devices configure the hardware into states approximating their on-boot EFI-support states; but it would just be an emulation at best. And some devices wouldn't have any kind of runtime state approximating their on-boot state (e.g. the CPU in protected mode doesn't have any state it can enter that approximates real mode.)

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

#382
post #345

Earlier quoted context omitted.

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.

Sure, but whether that GRUB entry is remembered as the default is up to the UEFI not GRUB. If you pick another entry GRUB is powerless to effect it.

The GRUB_DEFAULT and GRUB_SAVE_DEFAULT settings don't affect the UEFI settings, they only affect the default boot option in GRUB's boot menu. From the UEFI configuration perspective, the boot option never changes and it's always set as the drive with GRUB installed on it.

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

#383

Earlier quoted context omitted.

The distro could automatize the compilation of the kernel with ZFS on the user machine. In that case no license is violated as the kernel image is not distributed with ZFS. That would probably make updates a lot less slower than having zfs shipped in an initramfs though.

It doesn't really have to be slower as all that would be needed to do on installation is the final linking step. Linking prebuilt objects into a prepared kernel image shouldn't be inherently slower than assembling modules into an initramfs.

Doesn't that program that does the linking of the pre built objects into the prepared kernel itself a violation?

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

#384

Earlier quoted context omitted.

What I know or don't know is irrelevant, because what matters is that your statement rests of bringing in external knowledge/assumptions, so it's clearly not what the commenter is saying (alone).

Using external knowledge to interpret the meaning of sentences is how every communication works.

Indeed, but accusing someone of saying something based on unstated external knowledge/assumptions is the original problem here. They just needed to say words to the effect of "taken with point X what you say implies Y" and it would be fine and much less accusatory.

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

#385

Earlier quoted context omitted.

Using external knowledge to interpret the meaning of sentences is how every communication works.

Indeed, but accusing someone of saying something based on unstated external knowledge/assumptions is the original problem here. They just needed to say words to the effect of "taken with point X what you say implies Y" and it would be fine and much less accusatory.

I don't find "it sounds like you're saying" on a rather neutral technical topic to be very accusatory, personally.

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

#386
post #383

Earlier quoted context omitted.

It doesn't really have to be slower as all that would be needed to do on installation is the final linking step. Linking prebuilt objects into a prepared kernel image shouldn't be inherently slower than assembling modules into an initramfs.

Doesn't that program that does the linking of the pre built objects into the prepared kernel itself a violation?

IANAL but, for the most part, no.

The "problem" with the GPL here arises not when you, the end user, take a piece of GPL-licensed software and combine it with other software, as is your GPL-protected right, but when you try to redistribute the result. You see, every end user has the same right to obtain all of the source code for GPL-licensed software that they receive, and for all of that source code to be licensed in a way compatible with the GPL. Once the kernel and non-GPL-licensed modules have been combined into a single piece of software, you are free to use it locally as you wish, but you can't share it, because you would be unable to meet the obligations you owe to the person you give it to.

Bear in mind that the modules are meant to be combined with the kernel, and the method by which that happens isn't specified by the module authors. So, a tool which makes all of this easier for you to do isn't circumventing any restriction meant to stop you from doing this, because no such restriction exists.

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

#387

Earlier quoted context omitted.

Indeed, but accusing someone of saying something based on unstated external knowledge/assumptions is the original problem here. They just needed to say words to the effect of "taken with point X what you say implies Y" and it would be fine and much less accusatory.

I don't find "it sounds like you're saying" on a rather neutral technical topic to be very accusatory, personally.

Fair point. I should perhaps have said putting words in someone's mouth. Anyway far too much on this side point, I'll bow out here.

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

#388

Earlier quoted context omitted.

What is your actual need here? You talk about confusing documentation for a low-level process which basically no user is expected to go through if they aren't exploring the foundations of a linux system, or a developer working on their own distribution, and then complain that this is a lack of "a decent installer process".

It’s in the post, can’t you read? Also, something being low-level has nothing to do with documentation.

You broke the site guidelines badly in this thread. That's not cool, and we've had to warn you about this kind of thing many times over several years:

https://news.ycombinator.com/item?id=36316027 (June 2023)

https://news.ycombinator.com/item?id=36316001 (June 2023)

https://news.ycombinator.com/item?id=29959753 (Jan 2022)

https://news.ycombinator.com/item?id=28375317 (Sept 2021)

https://news.ycombinator.com/item?id=28375312 (Sept 2021)

https://news.ycombinator.com/item?id=28200716 (Aug 2021)

https://news.ycombinator.com/item?id=27157863 (May 2021)

https://news.ycombinator.com/item?id=26976826 (April 2021)

https://news.ycombinator.com/item?id=25129057 (Nov 2020)

We have to ban accounts that do this and I don't want to ban you, so if you'd please stop doing this, that would be good. Please stick to HN's rules no matter how provocative another commenter is being or you feel they are being.

https://news.ycombinator.com/newsguidelines.html

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

#389

Earlier quoted context omitted.

It’s in the post, can’t you read? Also, something being low-level has nothing to do with documentation.

You've complained about a lot of things, but I can only guess at what you are actually trying to accomplish, and you explicitly reject solutions which would actually resolve your problem. The first-party documentation for the linux kernel boot process is: https://www.kernel.org/doc/Documentation/x86/boot.txt . It's not the kernel's job to get itself into memory and pass it the required information about the system. T…

Please don't respond to a bad or provocative comment by breaking the site guidelines yourself. That only makes things worse.

Telling someone that they've "complained about a lot of things" or have "deliberately made this as hard as possible on [themselves]" is against HN's rules and guaranteed not to land well, regardless of how right you are or feel you are. Your comment would have been just fine without those bits.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

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

#390

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 than creating something separate. They also plan on reuseing grub's menu code, so it will have the exact same menu as grub.)

> The question is: that there are CVEs everywhere, we're not unique in this sense, and whether we would use systemd-boot.

> So, systemd-boot, it also works only on UEFI, and I believe that the plans are to keep it that way.

> Ultimately, the thing is that the kernel CVEs will get fixed no matter what, the question is: do we want to have more work fixing more CVEs. The kernel has a lot of developers, has very high visibility, and they're able to fix the CVEs in a reasonable time period. And, those aren't going to going to go away, the kernel CVEs aren't going to go away, whether we do this or not.

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

Post reply on HN