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

441–450 of 460 posts

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

#441

Post by mmphosis »

katzenversteher wrote: post #240
mmphosis wrote: post #221

A removable physical key: a programmable ROM. I have programmed the ROM to instantaneously copy my ROM to RAM and run. The entire system is running instantly as soon as I power on. There is absolutely nothing else. Because everything else is a big mess: Intel ME , BIOS, UEFI, kernels are signed by companies with Microsoft's blessing , EFI, FAT, TPM, anything with the word "Secure" in it, ...

Please elaborate. What kind of key are you using? What are you booting? On which architecture / machine?

> What kind of key are you using?

I want this because right now I use camera cards to boot. The key needs to be wired directly to the processor and be the first and only entry point. Instantaneous boot is what I want, not resuming from hibernation but "instant on" of the full system.

> What are you booting?

I am booting Linux, BSD, custom systems, lightweight bootstrap programs that do a specific task like diagnostics.

> On which architecture / machine?

Agnostic / various. For instance, instantaneously booting / running only on GPU(s).

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

#442

Post by StillBored »

No, please don't.

Most firmware systems don't enable interrupts, support paging, SMP, or many other things, for a long list of reasons, while at the same time, in order to enable a full Linux environment, ExitBootServices must be called, which is going to make a mess anytime the booting kernel isn't the right one. Kexec breaks a fair amount of the time if the target kernel isn't exactly what was already booted (ex, see kdump failures). Nevermind if the target OS isn't linux.

And for what? So /boot can stick around? A legacy partition left over from the days of BIOS/MBR like systems that have to have a small partition at the beginning of the disk, formatted with something that supports linux file permissions?

No, the right solution is to just place the kernel(s), and a small signed initrd (s) in the ESP, and nothing else besides a boot selector, like say systemd-boot to allow the user to select the correct kernel/OS, and optionally edit debug/etc options. Then, when the correct kernel is booted, it can bring up the network, filesystem, and whatever is needed.

That solves an endless list of Linux and firmware interaction problems that Grub currently solves, without all the file system, network code, etc., that one finds in Grub, which mainly duplicates the functionality already provided by UEFI.

The problem with this solution is that it doesn't work on systems that aren't UEFI, to which I might suggest that those systems (cough, legacy IBM junk, or hyperscalers still using BIOS boot after it has been deprecated everywhere else) have either uboot-uefi or edk2 ported so they can conform to modern boot standards.

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

#443

Post by StillBored »

aaronmdjones wrote: post #18
drewg123 wrote: post #2

I personally think they're moving in the wrong direction. I'd rather have "NMIRFS" (no more initramfs). Eg, a smarter bootloader that understands all bootable filesystems and cooperates with the kernel to pre-load modules needed for boot and obviates the need for initramfs. FreeBSD's loader does this, and its so much easier to deal with. Eg, it understands ZFS, and can pre-load storage driver modules and zfs.ko for t…

As other sibling comments have explained, an initramfs is usually optional for booting Linux. If you build the drivers for your storage media and filesystem into the kernel (not as a module), and the filesystem is visible to the kernel without any userland setup required beforehand (e.g. the filesystem is not in an LVM volume, not on an MD-RAID array, not encrypted), it is fully capable of mounting the real root file…

Not entirely, it is possible for simple boot solutions, but to enable LUKS and various other rootfs, it usually requires some userspace probing, authentication, etc. I'm not so sure it would be easy to convince the kernel maintainers to add a user prompt for pin code to the kernel just to avoid having an initrd.

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

#444

Post by michaelmrose »

prmoustache wrote: post #427
sqeaky wrote: post #418

Earlier quoted context omitted.

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

> Approximately half of gaming revenue is from PC customers Whales.

You are thinking of pay to win games with microtransactions. Whereas this trash HAS come to the PC platform there is no reason to believe it represents any substantial portion of the revenue in PC gaming.

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

#445

Post by mjg59 »

peter_d_sherman wrote: post #436
mjg59 wrote: post #129

Earlier quoted context omitted.

UEFI didn't exist at all on older systems, so instead you had BIOS which provided no security assertions whatsoever and exposed an even larger runtime attack surface (UEFI at least as the boottime/runtime distinction, and after ExitBootServices() most of the firmware code is discarded - BIOS has no such distinction and the entire real-mode interface remains accessible at runtime). In terms of how modifiable UEFI is -…

Anytime something (i.e., stack layer, software component, software layer, blob -- in this case, initialization/boot code for hardware which was first simple BIOS'es whcih became larger and more complex BIOS'es which later became still more complex UEFI -- a much larger attack surface by size) in technology is replaced by something new and complex which is touted as "more secure" -- it's usually less secure (bugs and…

Older BIOSes are much simpler, and also offer no security boundary at all - nobody talks about BIOS vulnerabilities because it wouldn't give you anything you don't already have!

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

#446

Post by delfinom »

tengwar2 wrote: post #309
prmoustache wrote: post #280

Earlier quoted context omitted.

> - it allows to dual-boot with Windows easily: motherboard boot menu is often not easy to access, you need to perform some key combination in a short window, also modern bootloader save the last boot option such that if Windows reboots for an update Linux does not start Do people really dual boot a lot in 2024? It was a good use case when virtualization was slow but decades after the CPU started shipping with virtua…

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.

Hilariously, the windows boot manager supports dual booting as well. So one can use it instead of grub to dual boot.

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

#447

Post by aaronmdjones »

StillBored wrote: post #443
aaronmdjones wrote: post #18

Earlier quoted context omitted.

As other sibling comments have explained, an initramfs is usually optional for booting Linux. If you build the drivers for your storage media and filesystem into the kernel (not as a module), and the filesystem is visible to the kernel without any userland setup required beforehand (e.g. the filesystem is not in an LVM volume, not on an MD-RAID array, not encrypted), it is fully capable of mounting the real root file…

Not entirely, it is possible for simple boot solutions, but to enable LUKS and various other rootfs, it usually requires some userspace probing, authentication, etc. I'm not so sure it would be easy to convince the kernel maintainers to add a user prompt for pin code to the kernel just to avoid having an initrd.

> it is possible for simple boot solutions, but to enable LUKS and various other rootfs, it usually requires some userspace probing, authentication, etc

I did mention that the root filesystem had to be both not encrypted and not require any userland setup.

> I'm not so sure it would be easy to convince the kernel maintainers to add a user prompt for pin code to the kernel

That wouldn't help, as the password is not usually used directly as a volume encryption key. In LUKS2 for example, a memory-hard KDF (Argon2) can be used to transform the password or PIN into a key-slot encryption key which is then used to decrypt that slot to obtain the volume encryption key (which is usually completely random and not at all related to or derived from any kind of password) in order to set up the dm-crypt mapping.

> just to avoid having an initrd.

No distribution has used an initrd in the last several years; initramfs reigns supreme now. They are not the same thing; an initrd is an image of a real filesystem (e.g. squashfs or ext2) that is read-only mounted onto / by the kernel during its startup, while an initramfs is (an optionally-compressed) cpio archive that is extracted to a read-write tmpfs (or ramfs if tmpfs is not available) mounted on / by the kernel during its startup and then the memory occupied by that cpio archive is freed because it is no longer necessary. An initramfs can also be built into the kernel image; an initrd cannot, and must be provided by a bootloader.

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

#448

Post by lofaszvanitt »

bayindirh wrote: post #435
lofaszvanitt wrote: post #434

Earlier quoted context omitted.

This isn't about your or my use case and/or preferences.

> This isn't about your or my use case and/or preferences. Exactly! This is why Linux kernel does and shall ship with a configuration which supports everything out of the box, even if it's slow. Because it covers everyone's use cases that way. If you need to trim it down to fit to your system(s), you should be able to do it. Debian has a mechanism called "Targeted Kernel" which removes the modules which won't be used…

Sigh... we are going in circles. You like the slow boot. You like suspending things, I'm against it. I'd rather not elaborate, because you will like the opposite of it, no matter what.

Everything is fine...

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

#449

Post by bayindirh »

lofaszvanitt wrote: post #448
bayindirh wrote: post #435

Earlier quoted context omitted.

> This isn't about your or my use case and/or preferences. Exactly! This is why Linux kernel does and shall ship with a configuration which supports everything out of the box, even if it's slow. Because it covers everyone's use cases that way. If you need to trim it down to fit to your system(s), you should be able to do it. Debian has a mechanism called "Targeted Kernel" which removes the modules which won't be used…

Sigh... we are going in circles. You like the slow boot. You like suspending things, I'm against it. I'd rather not elaborate, because you will like the opposite of it, no matter what. Everything is fine...

No, we are not. It's not a matter of slow vs. fast. It's a matter of resilient vs. fragile.

I prefer to have a resilient system in most cases, regardless of the form factor. If I was preparing an image for an embedded system, I'd go speed all the way down, within the limits of pragmatism.

I work in high performance computing. Speed is what we need, what we engineer for. However, resiliency is an equally important and valid concern. So, if I'm losing 5 seconds once a month (or once three-four months in case of desktop systems), that's a perfectly acceptable trade-off for a resilient system.

When a system tests its memory for 30 seconds, and initializes the motherboard and other devices for 3 minutes, losing 3 seconds on a bloody RAID speed test doesn't matter.

Oh, one of the latest servers we have exposes its management interface as a LAN port over USB, as I found out yesterday.

So, yeah.

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

#450

Post by lofaszvanitt »

bayindirh wrote: post #449
lofaszvanitt wrote: post #448

Earlier quoted context omitted.

Sigh... we are going in circles. You like the slow boot. You like suspending things, I'm against it. I'd rather not elaborate, because you will like the opposite of it, no matter what. Everything is fine...

No, we are not. It's not a matter of slow vs. fast. It's a matter of resilient vs. fragile. I prefer to have a resilient system in most cases, regardless of the form factor. If I was preparing an image for an embedded system, I'd go speed all the way down, within the limits of pragmatism. I work in high performance computing. Speed is what we need, what we engineer for. However, resiliency is an equally important and…

:˜˜˜˜DDDD Continue please.
Post reply on HN