Hacker News Reader

Comment by devaiops9001 | Hacker News Reader

It's all so tiresome. Just write these parts in Rust already.

Even better, dump that UEFI crap. Not even Rust can fix stupid.

Just directboot a static kernel and kexec() the real kernel -- like petitboot has been doing since forever: https://github.com/open-power/petitboot/blob/master/README.m...

Unless you like writing everything (display drivers, disk drivers, filesystem drivers, network stacks...) twice. Which is where these bugs come from...

I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.

They have a custom bootloader https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.

Yeah, if I remember correctly even AMD was amazed of what they did.

Oxide co-founder Jessie Frazelle published an ACM Queue article about the security advantages of open source firmware in 2019:

https://queue.acm.org/detail.cfm?id=3349301

It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control.

TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.

Others have already given good answers but also here’s a talk about this subject: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...

You'd need to either have drivers in the kernel for everything, with no common fallback ("the ARM approach"), or have standards at the hardware/HW firmware level. Having a firmware-level abstraction layer that papers over this for fallback may not be the best idea, but it works without too much politicking.

I would like to be able to ensure that only boot loaders signed with my private key can be executed. Secure Boot serves that purpose well, can I do that with your approach?

Likewise, demand and use cases for network boot exist, otherwise it wouldn't be here. Same goes for every other feature most users would consider bloat.

Yes of course you can. Just run `signify -V` in userspace under the pre-kexec() kernel to check the signature on the post-kexec() kernel/initrd.

You can network boot too; just run `busybox udhcpc`.

I think you misread my comment. I never described signature-checking or network boot as bloat. I said it was stupid to have to implement these things twice (once in mainline Linux and then all over again in kooky UEFI-land with its bizzarre API, ABI, and wacky rules).

I still think it is stupid to do that, because it is. We have working, high-quality, battle-tested implementations of all this stuff. Use them.

So here we have security vulnerabilities in an open source UEFI implementation, resulting in a thread about how UEFI is too complex. So your solution... is to use the actual Linux kernel plus some glue code as your boot firmware? I love Linux, but it is neither simple nor free of security vulnerabilities; what exactly does this buy us?

Edit: On reading another reply, I see your argument for having fewer implementations; that's not nothing, but it only really helps if everything is on Linux, which isn't going to help most desktops (and I hope we can agree that NT in firmware is not better) or the rest of the world that isn't on Linux (say, the BSDs).

This petitboot thing is very cool. Thank you for sharing this.

Just don't make something so complicated just to boot an OS. The damn thing is an operating system on its own now.

It's arguably less complicated than late stage BIOSes were, and I'm not including UEFI Class 1 systems (what many systems people thought still had BIOS actually were)

I used to think like that but I changed my mind.

I don't say UEFI is no over complicated, over engineered mess but I worked on embedded systems for a while and I'd say it's no sunshine there either. Booting a modern OS on modern hardware involves a lot of essential complexity you cannot get away from.

The design of UEFI also involves tons of non-essential complexity.

Sure, but it is easy to keep essentially simple things simple; accidental complexity is unforgivable in this case.

Systems that are inherently complex tend to naturally accrue accidental complexity. It's understandably hard to keep these systems lean.

My point is that modern boot systems in general fall into the second category, contrary to other comments that imply the first.

It just is that complicated to bring up all the pieces of hardware in a timely manner and with the right configuration. Not to mention if you want to let user configure things. Just look at say DRAM init: https://www.systemverilog.io/design/ddr4-initialization-and-... Of course you're gonna give that hard task to a memory controller, but then you have to initialise that. This goes on for all the subsystems, with complex interactions and features, all of which need handling.

It's not a single microcontroller you're powering on, even if it were, those too require a bunch of initialisation code to function properly.

DRAM init as little to do with UEFI or BIOS and Intel probably ships x86 components for more exotic or even allow custom bootloaders. At least at a time they did. I don't know the current situation but when I played with all of that, I saw one of their "Memory Reference Code" in particular the parts in charge of calibration of the memory controller timing, and that was a quite short piece of x86 assembly completely independent from the UEFI architecture insanities. Well because it was written in assembly it had an obvious bug, but that's another story.

I disagree. UEFI makes my life, as an end user, so much easier. The amount of times I've needed to buy a different flash drive because the BIOS of a particular motherboard didn't like the way my existing flash drives smelled has gone down to 0. The thing even supports filesystems _not_ formatted by a tool written for Windows 95 that arranges the FAT partition in _just_ the right way to get it recognised.

Previously, we had motherboards do the same stuff, except now they called into ROM memory on the network card, and ran a bunch of non-standard, proprietary code to render the fancy graphics and do online updating. I don't believe for a second that things were easier before UEFI standardised it all, they were just hidden from plain view better.

It helps that unlike with BIOS, the modern tooling doesn't have huge amounts of "we never read the spec but it booted on my machine" that was prevalent even with grub2.

TL;DR a BIOS doesn't have to boot a drive if there's no primary partition marked "active", no matter whether your boot code uses that or not.

I agree, but Rust would've still had several of these vulnerabilities. The integer underflow would've passed in release mode (though you could argue that anything running this low level should spare the extra CPU cycles for checked arithmetic), the infinite loops hanging the system, and the predictable TCP sequence numbers.

I'm not sure about the weak pseudo-RNG, because I would expect an existing crate to get imported for that use case, but the same RNG could also be implemented just as badly in Rust.

As for the buffer overflow vulnerabilities: I completely agree. These are the most dangerous vulnerabilities and I doubt they would've made it past the compiler had they been written in Rust.

Rust won't magically fix every vulnerability and someone would have to pay a team of engineers to rewrite everything.

> someone would have to pay a team of engineers to rewrite everything

A partial effort has already been made a while back: https://github.com/tianocore/edk2-staging/tree/edkii-rust

However, this uses uefi-rs, which is incompatible with TianoCore's BSD+Patent licensing, and therefore cannot be used as reference material, as the wiki page states: https://github.com/tianocore/tianocore.github.io/wiki/Tasks-...

More recent efforts have also been mentioned in the mailing list: https://edk2.groups.io/g/devel/search?p=recentpostdate%2Fsti... Rust also has a basic standard library implementation now: https://github.com/rust-lang/rust/pull/105861

Some of the challenges in adding Rust to EDKII are described in https://cfp.osfc.io/osfc2020/talk/SLFJTN/. There is some more recent work in this space described in https://microsoft.github.io/mu/WhatAndWhy/rust/, too.

Reply on news.ycombinator.com