Comment by collinmanderson | Hacker News Reader

Comment by collinmanderson | Hacker News Reader

Parent Full thread

collinmanderson

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.

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

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.

This seems like it could be a good use of rump kernels, although I don't think anyone has made a bootloader based on NetBSD rump yet. I've heard of efforts to rumpify Linux but I don't know if they are continuing. This seems like it could offer the benefits of each approach. The rump kernel paper has this brief paragraph on bootloaders:

> The lowest possible target for the rump kernel hypercall layer is ﬁrmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical ﬁrmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.

Reply on news.ycombinator.com