Hacker News Reader

Comment by rwaksmunski | Hacker News Reader

It is so disappointing that ARM and RISC-V is adopting UEFI, we had a chance of a clean break, but noo, let's make persistent firmware level root kits easy and cross platform with EFI bytecode. Yep, network stack with hard coded web addresses in your firmware, brilliant idea. /rant

View on HN

UEFI does not mean you need a network stack. Your dislike is of a particular implementation of the UEFI specification. The part of the spec that is being used is the contract between the bootloader and operating system which gets loaded. There are a large number of benefits that come from standardizing this interface, and most of the drawbacks you perceive can be avoided depending on how vendors go about the implementation.

I'm personally (uneducatedly) mostly for it because I like the way things "just work" on PCs. No matter what components you put on, the thing will boot. A sibling mentions that this is due to ACPI - I guess then I want that too.

Needing a separate build for nearly every different SBC sucks and I'm happy about anything that will broaden compatibility here.

It's entirely because it's expected in PCs and not expected on SBCs. Devicetree exists and can solve this problem, but it means the SBC and ARM SoC vendors would need to upstream their drivers like x86 vendors do. Until you have that ACPI vs devicetree is irrelevant for the purposes of improving this situation.

This is a narrow view. There are more operating systems out there than just Linux. Standardizing peripherals the ways PCs have done would have many benefits. Device tree basically forces operating systems to need per board images instead of a generic image that works on most boards. This doesn't scale well, especially on operating systems without a stable driver abi.

There's nothing about device tree which forces this. It's just how it's normally used because of said constraints. The ideal device tree situation would be it is provided by the SBC vendor and then passed into the generic image, just like ACPI. The reason this isn't done is this generic image doesn't exist at the moment. Switching to ACPI still means this generic image doesn't exist.

It's the reverse. DTs allow having a common image, where just the DT differs (and can be selected on boot, or passed from FW if it's not part of the OS image).

> Standardizing peripherals the ways PCs have done would have many benefits.

So, Linux's implementation would work well, whilst Windows has to pretend to be Linux in order to have it work mostly kinda unless the device explicitly supported Windows?

I'm reasonably confident that firmware/boot and drivers are orthogonal; consider that there are PCs with normal UEFI boot that will happily boot any Linux image you want but it'll come up without drivers because nobody's written them, or on the other hand the Raspberry Pi has open source drivers[0] but the boot situation is still its own bizarro thing that's unlike any other machine so you can't boot the same USB stick on a Pi and anything else[1].

[0] Weirdly not all upstreamed last I looked, but mostly.

[1] I mean, you might be able to put a Pi-compatible bootloader and, say, a UEFI+ARM bootloader on the same stick, but I mean with a single boot path.

UEFI is a necessary evil, we just have to get better, open-source implementations. Device Trees and alternatives are absolutely horrid especially in comparison.

Device trees aren't an alternative to UEFI, but to ACPI.

True, I skipped a step in my comment. My assumption is that ACPI and UEFI/BIOS usually exist together. Without UEFI you have to find an alternative to both, and neither DTs and the (bootloader) alternatives are pleasant.

What's so wrong with u-boot? Most of the trouble people have with it is "thanks" to chipset vendors who forked their version somewhere 10-ish years ago and completely mutilated it instead of putting in the effort to get their stuff upstreamed.

The only major thing it can't boot to my knowledge is Windows, but it might be doable if you chain-load Grub.

uboot needs to be modified to run a given operating system if it wasn't already supported (or a shim pretending to be one of the supported operating systems needs to be used). UEFI provides a way to support all operating systems through a standardized interface. uboot implementing UEFI interface provides the best of both worlds.

"implement just enough UEFI to boot stuff, not the whole kitchen sink" I believe is the target of the uboot project

ACPI table issues are just as unpleasant as devicetrees if not moreso.

What makes x86 feel nicer is that most of the peripherals fall into two categories: 1) Standardized for the arch, so their configuration can be assumed and hardcoded, or 2) Attached to a bus that can be dynamically enumerated (i.e. USB, PCI, etc.) This generally makes the per-system configuration relatively simple.

Embedded systems are not like this. Each SoC is effectively its own system architecture that just happens to share a CPU instruction set with other systems, and the devicetree ends up being the description of this architecture. So it looks gross and ugly and complex by comparison, but the complexity of defining peripherals for a system has to exist somewhere!

The messy bits are, of course, that both the OS and bootloader need access to subsets of this data, and you'd like to ship the tables with the bootloader for a SoC (so the OS can be gneeric and not care), but really, the bootloader only needs a little bit of this, and the OS needs almost all of it... and this leads to coupling between the two being tighter than it should be.

Coreboot does ACPI just fine.

> Device Trees [...] are absolutely horrid especially in comparison.

Care to elaborate? I only have a passing interest in the ACPI / UEFI / Open Firmware / device trees / etc. story, but I haven’t encountered anything particularly awful about device trees, or (until you) anybody saying there was.

Device trees are what you get if you don't implement ACPI.

While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64.

ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured.

With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...

On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows.

ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,

Device Tree can be compiled to a separate file, then loaded by boot loader and kernel. When device tree is available and all drivers are present for a device, then it's easy to boot it.

Devicetree is in effect doing the same thing as ACPI tables. It actually usually is passed into the kernel by the bootloader. The main thing that prevents having one vanilla kernel that works on most ARM SBCs (where the vendor only provides a devicetree like they provide ACPI tables) is the fact that most of them don't have full upstream support so you need to run a custom kernel anyway. (Secondly, because it tends to be used primarily on systems where you are building your own patched kernel anyway, most devicetrees are not so much a generic description of a device as initialisation data for a specific driver)

Lack of peripheral standardization is a big piece too. You're not going to include every possible arm peripheral driver in your image. There are far fewer drivers necessary to include on PC by comparison (and they are often less space constrained anyways so including those drivers isn't a big deal).

It's not much different. PC linux distros already bundle basically all the device drivers for not just the PC box itself but all the peripherals you might plug into it. The ARM ecosystem if anything has fewer peripherals, it's just not upstream.

There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.

ACPI is executable code.

"Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1]

And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2]

[1] https://en.wikipedia.org/wiki/ACPI

[2] https://issuepedia.org/1999/01/24/ACPI_extensions

This is semantics at this point, but ACPI "is" not executable code. It contains executable code in form of methods, but it is a structured container for many types of data (they are called "tables" for a reason). You could very well embed DT in ACPI and there are platforms out there which do that.

I think device tree, as opposed to something that can enumerate whatever hardware is present, is part of the reason that you have separate ROMs for every single Android phone. (Whereas a single Linux ISO can run on just about any PC out there.)

It's definitely only part of the reason. If it were the only reason, it would be easy enough for a 'unified' ROM to contain config/devicetrees for a few thousand models of phone, and auto-select which one to use at boot time depending, for example, on a commandline flag.

That's not the reason. Have you seen the size of the average kernel that can boot on just about any PC out there? It's 10MB kernel code and easily 100MB initramfs, depending on how many video card firmwares you intend to support. And that's on a relatively "standardized" PC platform, with generic ACPI/PCIe/SATA device abstractions in the hardware.

ARM has none of that: no standardized platform, no device discovery through bus enumeration, no standard VESA graphics implementation. Device tree is a consequence of the non-standardization of ARM devices, not the cause. You could easily have the devicetree in the phone's ROM (just like ACPI, but without the executable code vector) and have the kernel read that data on startup. But you would need a kernel of at least the same size as the PC kernel+initramfs; and unlike on PC's, on phones people still (somewhat) care about code size and performance.

The DT is actually there to avoid recompiling the kernel for each specific device. But probably tons of vendor do not understand the purpose.

I'm not a huge fan of DT, but I've also reversed an UEFI bios once and I absolutely detest that hot pile of garbage. Obvious insane MS influence, with e.g. too many GUID everywhere for no reason. Overall astronaut architecture with gratuitous phases. Humongous abstraction layers that are not even optimized out at compile time and replaces a single "out" instruction by object oriented crap with virtual layers probably involving GUID. Scope insanely large. Insane vulns over and over again with some that completely break the PC security model for years, AND hinder maintainability at the same time. Berk. That's one of the reason that makes me want to use Macs everywhere (well maybe it is just because I don't know enough how their bootloader is designed and it is actually worse)

M1 Macs don’t have UEFI, just a very limited system that can boot macOS from the SSD. The boot menu is macOS. The initial firmware has no drivers beyond the SSD. That’s why there is such a long delay between power on and the screen displaying the logo. And why there are no keyboard shortcuts. And why it doesn’t support external boot discs.

https://news.ycombinator.com/item?id=26114417

https://support.apple.com/guide/security/boot-process-secac7...

On RISC-V, UEFI (typically edk2) is a payload for SBI (typically opensbi).

If you hate edk2, you can run something else e.g. u-boot, the linux kernel or your own code.

If you hate opensbi, look at oreboot, which implements something equivalent to u-boot SPL + opensbi in rust.

Hardware root kits make me lose sleep at night - has there been evidence outside of academia that they’re used?

Yes, for a long time. Criminals have used hardware rootkits since at least 2008, but the most famous one is Intel Active Management Technology.

Wikipedia explains:

> Intel Active Management Technology, part of Intel vPro, implements out-of-band management, giving administrators remote administration, remote management, and remote control of PCs with no involvement of the host processor or BIOS, even when the system is powered off. Remote administration includes remote power-up and power-down, remote reset, redirected boot, console redirection, pre-boot access to BIOS settings, programmable filtering for inbound and outbound network traffic, agent presence checking, out-of-band policy-based alerting, access to system information, such as hardware asset information, persistent event logs, and other information that is stored in dedicated memory (not on the hard drive) where it is accessible even if the OS is down or the PC is powered off. Some of these functions require the deepest level of rootkit, a second non-removable spy computer built around the main computer. Sandy Bridge and future chipsets have "the ability to remotely kill and restore a lost or stolen PC via 3G". Hardware rootkits built into the chipset can help recover stolen computers, remove data, or render them useless, but they also present privacy and security concerns of undetectable spying and redirection by management or hackers who might gain control.

https://en.wikipedia.org/wiki/Rootkit#Firmware_and_hardware

Not sure that if you pay extra for vPro on your computer and it comes with a vPro sticker on the front, that counts as a rootkit.

Well, except for the 100s of bugs in vPro that cause it to completely insecure...

These are all solving use cases. What do you suggest hardware vendors should do?

Apple created a minimal bootloader for their Apple Silicon machines, seems to be working great.

Apple also controlls their entire software and hardware stack, a bit different

Oxide managed to do something similar as well: https://github.com/oxidecomputer/phbl

Oxide also controls their entire software and hardware stack (theirs is open source, at least)... Neither vendor has to worry about modularity or weird configurations.

Open their software drivers and publish accurate specifications.

And then what? We implement a dozen different incompatible bootloaders for it? The value in UEFI is that it lets us use a common interface for booting, regardless of how it's implemented.

(To be clear, I overwhelmingly prefer FOSS and open specs, but we need to be clear about what things solve what problems)

Reply on news.ycombinator.com