Hacker News

points by hn_submit 2 days ago | 0 comments

I've always been downright suspicious of the creation of UEFI. It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does. Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?

And unlike BIOS which is relatively small UEFI is "full-fat" almost the size of an operating system itself. It can even run its own applications.

The 1 million lines of C code comprising UEFI are riddled with bugs and this is just one of them. No doubt LLMs will be able to uncover a lot more of them.

[–] yjftsjthsd-h 2 days ago

> It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does.

Yes it does? If anything, it provides way more; a .efi program can use firmware services to load files and print text. There's like 80% of a DOS in there.

> Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?

Because we still want enough functionality to load the OS in the first place, which means e.g. nvme drivers, Ethernet drivers (for netboot), keyboard input and some display output (to let a user pick what to load), and of course filesystem drivers because loading an OS/bootloader from a single shared MBR was awful.

[–] preisschild 2 days ago

they also provide device trees to the kernel on modern arm uefi environments. And in servers they provide an interface for the baseboard management controller to interact with the firmware directly.

[–] orbital-decay 1 day ago

If you want an OS to handle edge cases like booting from the network (that can be arbitrarily complex), reusing an existing one makes a lot more sense than writing a custom one from scratch. Make a very basic bootloader that will init the minimal amount of hardware and then load a user-supplied boot image from the flash. That's it. Linux typically boots this way on non-embedded systems.

[–] yjftsjthsd-h 1 day ago

What operating system would you use, that is small enough to be burned into a flash chip on the motherboard, and capable of booting arbitrary target operating systems?

[–] orbital-decay 1 day ago

Linux, for example? 32MB is several times bigger than your average OpenWRT image. If you need more for the drivers or anything else then you already have more on your motherboard, and surely won't be limited by the OS overhead.

[–] yjftsjthsd-h 1 day ago

I said "and capable of booting arbitrary target operating systems" for a reason. Linux can kexec itself and I believe modded (but not mainline) FreeBSD. UEFI is rather more general.

[–] mkopec 1 day ago

may I introduce you to coreboot and LinuxBoot?

[–] mjg59 2 days ago

> doesn't really provide a hardware abstraction layer like BIOS does

I'm not really sure what this means. UEFI provides a consistent interface to access storage devices, network devices, input devices, and access to a framebuffer. How else would bootloaders work?

[–] hn_submit 2 days ago

Hint: they use BIOS, which is still present on all modern PCs. Even if UEFI provides something similar it's way too fat.

And why do I need mouse and network? Just so the BIOS firmware can show me a graphical interface and connect directly to the internet?

[–] mjg59 1 day ago

No, no modern OS uses any BIOS calls on UEFI systems, and CSMs are disabled by default on any system sold with secure boot enabled (ie, everything sold with Windows pre-installed)

[–] mjg59 1 day ago

Oh, sorry, I didn't answer the other part of your comment. Network is required so you can boot from the network, which is commonly used for reimaging systems (not just servers, it's often done for laptops in enterprise environments). Non-keyboard input is a necessity for any devices that don't have a keyboard, but mouse input is also just what users expect these days.

[–] blueflow 1 day ago

bro you responding to Matthew Garret. I don't want to defend either of you two but you set the bar pretty low.

[–] RobotToaster 1 day ago

Apparently that's someone mildly important, for anyone else who's never heard of him https://en.wikipedia.org/wiki/Matthew_Garrett

[–] cowlevel 1 day ago

I always recognise him but all I know him for is for being someone who techrights (Roy Schestowitz) is/was irrationally mad at. Good to see he won his harassment lawsuit.

[–] kasabali 1 day ago

https://www.logicallyfallacious.com/logicalfallacies/Appeal-...

[–] mjg59 1 day ago

If an authority on a topic says something and someone with no demonstrated experience on that topic disagrees with them without providing any evidence, that's not really an argument to authority kind of situation.

[–] nicman23 1 day ago

i mean yea but in this specific argument the authority is correct lol

[–] imoverclocked 2 days ago

Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.

[–] preisschild 2 days ago

some arm64 sbcs support edk2/uefi btw. I make sure I just use those. Look for "Arm SystemReady" certification, which requires this

[–] yjftsjthsd-h 1 day ago

Any chance you could recommend a board or two?

[–] preisschild 1 day ago

I'm currently using the Radxa Q8B, which already includes EDK2 OOTB and provides the device tree to the linux kernel. But its still a new board and some things are not supported in mainline linux yet.

There are also less-powerful RK3588-based boards like the Radxa Rock5 series which are supported by this edk2 port: https://github.com/edk2-porting/edk2-rk3588#platinum. Thanks to collabora the mainline support is quite advanced: https://gitlab.collabora.com/hardware-enablement/rockchip-35...

If you are searching for more powerful enterprise hardware, AmpereOne SoCs have ARM SR certification. You can just use any modern linux distro uefi generic aarch64 iso and it will boot.

[–] yjftsjthsd-h 2 days ago

I think uboot is kinda doing that?

[–] arcfour 2 days ago

You need to compile a device tree for every single device you want to support individually, whereas x86 has ACPI to avoid that mess. ACPI is its own mess, yes. And UBoot is great. But it isn't a standalone replacement for a unified firmware interface/"BIOS"/whatever.

[–] cowlevel 1 day ago

It's basically the same solution just in a different format. Device tree specifies device types while ACPI specifies the bytecode to interact with them, but the idea behind both is the same: the computer firmware tells the OS how to interact with it. It's been a slight success in both forms but not nearly as good as you'd hope it to be. The real problem is that nobody's testing all the firmwares and OSes for compliance so lots of devices ship incorrect data in firmware and then the OS has to patch it anyway.

Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.

[–] imoverclocked 1 day ago

Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.

When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.

There should be no need for any of this in 2026.

[–] cowlevel 1 day ago

How should it be solved instead?

[–] imoverclocked 1 day ago

Well, for one, the dtbs don't belong with the shipped kernel. If a dtb exists, it should be shipped on the hardware (perhaps as part of firmware.) Right now, there is an intricate dance in some arm setups where:

The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.

One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.

One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.

Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?

So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.

IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:

1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom * This is likely on the board-manufacturer to provide and should be pre-loaded.

2) Run a generic arm64 installer.

[–] kasabali 1 day ago

BIOS had ACPI, too, so I'm not sure how it contributes to the argument.

[–] kbolino 1 day ago

BIOS had to be replaced. It didn't have to be UEFI, but it did need to be something, even just a new 64-bit stage would have gone a long way. But nobody made such a thing, and the alternatives that actually exist like Coreboot do a lot less even than BIOS did. Past a certain point, pretending to be smol-bean 1980s/'90s hardware stops being a fun game and starts being a real limitation holding things back. Said "hardware abstraction layer" was getting to be more like a bunch of increasingly hard-to-maintain lies told to BIOS rather than a real service provided by BIOS.

[–] blablabla123 2 days ago

The value of UEFI is surely dubious. I recently had to update my BIOS using Windows PE since there was no way of doing this on Linux. Of course my default boot was reset. The funny thing was though that I could repair my Linux boot using Win PE.

Before the only way was either fdisk /mbr to reset for Windows or boot a Linux system on stick/CD and rebuild grub/lilo. The latter has gotten unreasonably complex though so I rather wouldn't do this manually.

My verdict is that UEFI does something right, but created for the enterprise sector carries way too much complexity. Obviously so complex that everybody ends up using the original same code base.

[–] jeroenhd 2 days ago

Your computer's awful implementation says nothing about UEFI as a whole, it just means that the vendor you bought your hardware from sucks at writing firmware. I update my UEFI from the standard fwupdmgr command in Linux and it maintains the standard bootloader. In fact, unlike BIOS, it allows me to select a bootloader on startup if I want.

The absolute hackery that was necessary for BIOS to do something as basic as booting an operating system was due for removal. And looking at the rest of the bootstrapping landscape (ARM phones, Linux routers, you name it), I'll take UEFI over any of its competitors any day of the week.

[–] za_creature 1 day ago

Unfortunately, there's plenty of vendors that suck at writing firmware, and most usually give up on updating it immediately after they've EOL'd the hardware revision. The hackintosh project mostly works by replacing the bugs from the vendor firmware into the bugs that apple expected from their x86 line of pcs.

If most vendors suck at writing firmware, it might be a problem with the spec though.

[–] jeroenhd 1 day ago

BIOS didn't have a spec at all, it was hacks stapled to reverse-engineered chips that were Good Enough To Ship for IBM decades ago.

Most of the alternatives require brand+model specific kernels and boot mechanisms, at least UEFI has a standard. I dream of the day smartphones run UEFI instead of the weird factory bootloader + custom uBoot mess that we're in right now.

[–] za_creature 1 day ago

Look, it's a step in the right direction for sure. It's just too big of a leap for my taste.

To boot an OS you need to initialize core 0, RAM and some storage controller. Throw in a serial port for debugging. Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.

Having a display, mouse, keyboard or network is an opinion. GUID partitions are an opinion. And if it comes to opinions, I'd rather all of the extras be handled by third parties instead of within a giant spec that will be vibe-conformed to.

[–] jeroenhd 1 day ago

Initializing core 0 on a modern system requires a Pentium CPU preconfiguring Minix to bootstrap the CPU. Training RAM is a whole new challenge. The simplistic designs of the 20th century don't apply anymore. Having USB to control boot is a necessity now and with Thunderbolt offering DMA access, configuring trust at a low level has also become a requirement.

There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.

I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.

[–] za_creature 1 day ago

Yeah, and booting the raspberry pi is done via the GPU. What was that you were saying about shitty vendors?

USB is a value-added feature (with a spec that rivals UEFI in complexity), and despite having owned 5 apple machines, I'm not sure I have ever used thunderbolt... EVER

With regards to trust, the only reasonable approach is "can be overridden by the legitimate owner" with a "delete everything on request by whomever has physical access to the device" fallback. Yeah, theft will be a problem but 1984 would be a bigger problem.

[–] yjftsjthsd-h 1 day ago

> Everything else should probably be left to whatever is running at the initialization vector of the storage. Which, if you'd like, can be a complete UEFI implementation.

Putting it all in a single location on the storage device means that 1. Multibooting will always suck because Windows will unconditionally overwrite whatever is there with its own bootloader that only boots Windows, and 2. you now have to have local storage, which would be somewhat annoying to those of us trying to do diskless network boot (or anything else more interesting than "always boot internal disk0").

[–] za_creature 1 day ago

You always have local storage, even if it's a 128Mbit flash chip that stores the firmware. There's no network boot implemented in hardware.

[–] cowlevel 1 day ago

That's how it works on ARM, but other people in this same comments section are complaining about having to build u-boot and Linux differently for every device model because there's no commonality.

Also why initialize RAM? Isn't cache-as-RAM enough for a stage zero bootloader?

[–] za_creature 1 day ago

Eh, I was thinking more along the lines of populating the memory regions mapped to hardware.

Having to build u-boot for every device model is a good thing, it means that there's less functionality abstracted-away by some never-to-be-updated vendor-provided firmware.

[–] kbolino 1 day ago

> Your computer's awful implementation says nothing about UEFI as a whole

This is just a copout. Of course the crappy implementations many people have to deal with cast the whole thing in a bad light. If nothing else, UX is a distant-to-nonexistent concern of the UEFI standards, and that's part of the problem.

However, you are also right that this doesn't hardly make UEFI any worse than BIOS.

[–] jeroenhd 1 day ago

UEFI has standards for things like automatic updates issues from the OS: https://www.preprints.org/manuscript/202502.1245

Needing to do special Windows boot and somehow wiping the boot config has nothing to do with the standard.

UX is meaningless for a boot mechanism standard. You cannot apply the same requirements to all UEFI devices. Tablets need touch-sensitive operations that work without keyboards. Servers need headless management with detailed configuration available through remote management. Desktops and laptops a mix of both. Managed Linux environments such as Chromebooks need a whole different sort of boot mechanism where the user has minimal control.

The update delivery mechanism is specified already. Wiping user settings can also be a necessity. Could be to prevent malicious firmware downgrades, could be to clear out NVRAM-triggered exploits, or maybe because the update necessitated restructuring configuration or whatnot.

Plus, as many have probably already noticed, the UEFI spec is more of a suggestion anyway. The only party bothering to check it might be Microsoft, and even then they only care about the parts that make Windows work. No matter how good or specific your spec is, a shoddy company will release shoddy firmware for it.

[–] kbolino 1 day ago

> UX is meaningless for a boot mechanism standard.

Well, all I can really say to this is that yes, this attitude is exactly the problem here.

Of course, the world looks different now than it did 25-30 years ago, and all Intel really set out to do back then was to get away from BIOS and all of its limitations. This was especially important for their now-defunct "IA-64" (Itanium) project, but it ended up lasting anyway due to x86-64 happening.

Nevertheless, for most of us, UEFI rolled out in the 2010s, at a time when Internet connectivity was generally a given, and hardware capabilities had already moved well beyond where they were when Intel handed the matter off to UEFI in the 2000s.

Hardware makers have consistently shown contempt for software and user experience, regarding it somebody else's problem. Of course, a consortium of many hardware makers is not likely to develop opinions or sentiments that none of them individually would have. But it does show how parochial and short-sighted they were and often continue to be.

Yes, there are multiple different platforms that use UEFI. They can each have their own standard way of using it, though.

[–] blablabla123 1 day ago

Yeah, probably it doesn't make things better that the vendor is Lenovo. I think for some models fwupdmgr might work but not for everything.

[–] p_l 1 day ago

"Think" (thinkpad, thinkcentre, etc.) series have AFAIK completely different R&D team plus the whole aspect of building on top of what was done for earlier models, and on those the UEFI Capsule mechanism (which allows passing firmware updates from booted OS to firmware) works just fine - it's also used to ship firmware upgrade as part of Windows Update.

[–] jeroenhd 1 day ago

Lenovo's business/prosumer line is one of the best in terms of firmware that I've seen so far (though I do have my gripes with their decisions on laptops with Nvidia GPUs).

I don't even want to touch Lenovo devices that don't have "think" in their name, and even that has been tainted by their consumer brand at this point.

[–] ndiddy 1 day ago

> Lenovo's business/prosumer line is one of the best in terms of firmware that I've seen so far

A few years ago Lenovo put out a buggy firmware update for the Thunderbolt controllers in a couple generations of Thinkpads (the list is here: https://pcsupport.lenovo.com/ca/en/solutions/ht508988 ) that caused excessive writes to the controller's EEPROM. This would eventually wear out the EEPROM, which would stop the controller from functioning. You would then have issues like USB-C devices not working, display over USB-C not working, and charging over USB-C not working. Lenovo released a firmware update to fix the issue, but everyone whose controller had already broken needed a motherboard replacement. If your device was out of warranty, Lenovo made you pay full price for the new motherboard even though it had broken because of their firmware update.

[–] cowlevel 1 day ago

In countries with consumer protections you probably could've gone to court and won. The warranty period wouldn't matter, since they caused the damage.

[–] jeroenhd 1 day ago

I am aware and my laptop was one of the devices that needed the patch.

And yet, I'm still of the opinion that Lenovo's firmware is up there. It's actively maintained and it fails less often than the firmware I've experienced from other brands.

This is less of a compliment to (a branch within) Lenovo, and more of an insult to other brands; production quality for computers and laptops is absolutely awful unless you pay a ridiculous amount of money for the "pro" branding.

[–] esseph 1 day ago

> probably it doesn't make things better that the vendor is Lenovo.

You mean, arguably the best vendor of linux laptops since 2005?

Just google around.

[–] p_l 1 day ago

UEFI provides a way to update in OS agnostic way, unfortunately motherboard vendors do not necessarily provide archives that can be uploaded this way (assuming they updated to new enough version to support the interface in the first place).

Unfortunately we're suffering from "eh, it boots windows, ship it" mentality of many hardware manufacturers, whether back in horrible era of BIOS emulating faux IBM PC 5150, or with modern UEFI

[–] esseph 1 day ago

> The value of UEFI is surely dubious. I recently had to update my BIOS using Windows PE since there was no way of doing this on Linux.

That sucks. I'm able to upgrade the firmware of my checks 8 year old motherboard and its backup firmware from a linux shell.