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

121–130 of 460 posts

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

#121

Post by peter_d_sherman »

mjg59 wrote: post #70
peter_d_sherman wrote: post #57

>"Although GRUB is quite versatile and capable, its features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes." We agree thus far -- that GRUB may create unnecessary complexity and security holes (Note the relationship between "complexity" and "security holes" -- where you find one, you will usually find the other... t…

The UEFI environment is a given, unless you're in a position to replace the firmware - using grub doesn't avoid it in any way. But for the most part the security properties of the underlying firmware don't matter that much if the attack surface it exposes can only be touched by trusted code, which is the case if secure boot is enabled (and if secure boot isn't enabled then there's no real reason to bother attacking t…

The UEFI environment does not exist on older PC's.

UEFI started to become mainstream around 2013 -- that is, an increasing amount of PC motherboard manufacturers started to put it on motherboards (rather than the older BIOS) around this time.

It should be pointed out that on some motherboards the UEFI software may be placed on an IC (EPROM, EEPROM (Electrically Erasable Programmable Memory), Flash, NVRAM, ?) -- which may be writable, or writable under certain conditions (i.e., if the boot process doesn't load software which explcitly blocks this when the system starts up, or if such blocks, once existing, are bypassed, by whatever method...)

If the UEFI-storing IC is writable (or that IC replaceable, either via socket or solder), then the UEFI (again, under the proper conditions) is subject to modification then it is modifyable; changeable; updatable, programmable; etc. etc.; use whatever linguistics you deem appropriate...

>"The UEFI environment is a given, unless you're in a position to replace the firmware"

If what I've written above is the case -- then any such UEFI envrionment (aka "firmware") under such conditions is very much replaceable!

And if it is replaceable, then that firmware code can be made simpler by somone "rolling their own" -- and replacing it!

Now that I think about it, I'm going to have to do more research for the next motherboard I buy... if it has to have UEFI on it, if I am compelled to buy a UEFI motherboard, then I want that UEFI firmware to be overwriteable/customizable/modifyable/auditable -- by me!

Also -- I'd never trust "trusted" code implicitly...

Didn't Ronald Reagan so eloquently say "Trust -- but verify?"

It's the but verify part -- that's key!

Anytime a security vendor or vendor (or any authority or "authority" for that matter) tells me to trust or "trust" something, my counterquestion is simply as follows:

"Where is the proof that the thing asking for my trust is indeed trustworthy?"

In other words,

"How do I prove that trust to myself?"

?

In other words,

"Where is the proof?"

?

And let's remember that proof by analogies (Bjarne Stroustrup) and proof by polled social approval consensuses ("4 out of 5 dentists recomend Dentyne for their patients that chew gum") -- are basically fraud...

Anyway, your assessment, broadly speaking, is not wrong!

It's just that there are additional "corner cases" which require some very nuanced understandings...

Related:

https://en.wikipedia.org/wiki/Open-source_hardware

https://en.wikipedia.org/wiki/Right_to_repair

https://en.wikipedia.org/wiki/Non-volatile_memory

https://libreboot.org/

https://www.coreboot.org/

https://en.wikipedia.org/wiki/Open-source_firmware

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

#123

Post by zauguin »

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…

This is a step in that direction. What they are proposing is not so much "no bootloader" but using a small Linux as bootloader. I'm using a similar setup for some time and it gives some of these advantages. Especially you get support for all relevant filesystems (you can support everything Linux supports because it is Linux), it can dynamically build a minimal initramfs with only the needed drivers if you want to and understands module dependencies (e.g. it can just dump the list of modules it uses itself) and is generally much more flexible.

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

#124

Post by ssl-3 »

linsomniac wrote: post #92
ta8645 wrote: post #7

Earlier quoted context omitted.

The Linux kernel does not require an initramfs. You can build a kernel with everything compiled in; with no modules needed at all. Initramfs is used for generic kernels where you don't know beforehand which features will be required. This allows you to avoid wasting RAM on features you don't use. But it is optional.

Is anyone really wanting to get back into the business of building their own kernels? I started using Linux heavily in '92, and I've built a lot of kernels, and am quite happy to not be building them anymore.

I kind of liked compiling my own kernels. I felt I was better-connected to the state of things, and it was fun to see it all evolve from the vantage point of "make menuconfig".

But initramfs isn't so bad, and it allows things like ZFS root to have a modicum of smoothness and integration.

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

#125

Post by joe5150 »

ziml77 wrote: post #118
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…

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

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

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

#126

Post by superb_dev »

bityard wrote: post #108
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…

Let's say I have a dual-boot system with two totally independent OSes, Systems A and B. It is powered down. I want to boot into System B but the EFI is configured to boot into System A by default. Am I correct in understanding that the offered solution here is to first boot into System A, find some well-hidden EFI configuration utility (which varies from OS to OS, if it even exists), and then tell EFI to boot into Sy…

Presumably nmbl would show you a menu to select the which OS start if you’re dual booting. You wouldn’t have to manually set some UEFI variable

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

#127

Post by aaronmdjones »

medstrom wrote: post #110
kbolino wrote: post #81

Earlier quoted context omitted.

Given the reason why "out-of-tree modules" exist, there's really no way to eliminate initramfs or something like it entirely in the general case. It might be possible to speed up the process of building the image (as long as the results are not "redistributed"), but this is a licensing and legal problem, not a technical one. FreeBSD is under a much more permissive non-copyleft license and so can legally bundle things…

You're talking about something like ZFS, and I get that they can't just compile it in, but a distro can still ship the module, if I'm not mistaken. ...But to load it at boot time it absolutely must be done through an initramfs. Is that right?

> But to load it at boot time it absolutely must be done through an initramfs. Is that right?

Yes, because it cannot be part of the kernel image, or it would be illegal (a violation of the GPL license) to distribute that kernel. Therefore, it must be a module, and that module has to live somewhere and be loaded by something. If root is on ZFS, this must therefore live in an initramfs and be loaded by it so that the initramfs can mount the real root filesystem on the kernel's behalf.

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

#128

Post by vlovich123 »

mjg59 wrote: post #107
vlovich123 wrote: post #101

Earlier quoted context omitted.

Does the kernel actually support doing that? The pitch is that they already have all the pieces and don’t need to do any kernel work to enable this.

Module loading is handled by udev, so udev merely needs to support enumerating a subset of the hardware to (eg) ensure input devices are available.

Again, I think you’re thinking I’m saying which I’m not. I’m not saying it’s impossible. I’m suggesting the scope of work may be harder than they pitched which is that they have all the pieces and don’t really need to do much other than some packaging & some EFI integration. UDEV changes and kernel patches (more than the trivial 2 they have right now) would prove that the idea requires more work than anticipated.

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

#129

Post by mjg59 »

peter_d_sherman wrote: post #121
mjg59 wrote: post #70

Earlier quoted context omitted.

The UEFI environment is a given, unless you're in a position to replace the firmware - using grub doesn't avoid it in any way. But for the most part the security properties of the underlying firmware don't matter that much if the attack surface it exposes can only be touched by trusted code, which is the case if secure boot is enabled (and if secure boot isn't enabled then there's no real reason to bother attacking t…

The UEFI environment does not exist on older PC's. UEFI started to become mainstream around 2013 -- that is, an increasing amount of PC motherboard manufacturers started to put it on motherboards (rather than the older BIOS) around this time. It should be pointed out that on some motherboards the UEFI software may be placed on an IC (EPROM, EEPROM (Electrically Erasable Programmable Memory), Flash, NVRAM, ?) -- which…

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 - this is what Boot Guard (Intel) and Platform Secure Boot (AMD) are intended to deal with. They both support verifying that the firmware is correctly signed with a vendor-owned key, which means it's not possible for an attacker to simply replace that code (at the obvious cost of also restricting the user from being able to replace it - I don't think this is a good tradeoff for most users, but it's easy to understand why the feature exists).

If you want to be able to fully verify the trustworthiness of a system by having full source access then you're going to either be constrained to much older x86 (cases where Coreboot can do full hardware init without relying on a blob from the CPU vendor, ie anything supported by Libreboot) or a more expensive but open platform (eg, the Talos boards from Raptor). If you do that then you can build this entire chain of trust using keys that you control, and transitively anyone who trusts you can also trust that system.

But there's no benefit in replacing all of the underlying infrastructure with code you trust if it's then used to boot something that can relatively easily be tricked into executing attacker-controlled code, which is why projects like this are attempting to replace components that have a large attack surface and a relatively poor security track record.

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

#130

Post by jmb99 »

samsartor wrote: post #36

My previous laptop was a Chromebook running Linux+Coreboot. Unfortunately the usual Tianocore UEFI BIOS people use had some bugs in the nvme and keyboard drivers, which I gave up fixing or working around (at the time). Obviously Linux had working drivers because that's all ChromeOS is, so we setup a minimal Linux install as the Coreboot payload in the firmware flash, and I wrote a little Rust TUI to mount all visible…

> I don't see any reason why we don't just use Linux direct instead for everything.

Because that would only allow you to boot Linux kernels. One of the benefits of bootloaders is the ability to boot other OSs. You can’t kexec windows.

Post reply on HN