We recently wrote about moving away from OVMF (~1M lines of C) to very minimal and hyperspecific firmware (300 lines of assembly)[1] for our specific confidential VM machine targets, and the idea that "popular" does not automatically mean "secure". You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable. You can instead just write hyperspecific, small codebases and throw all the security practices at it - like LLMs (economical if it's small), fuzzing, formal methods etc.
We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.
When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.
Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.
"""
An initial inquiry blamed the collapse on the Pal-Kal method of constructing light-weight coffered concrete floor systems which was banned shortly after …
Late in the construction process … a third storey was added. … the structure supporting the new third storey was subjected to much greater loading than was originally anticipated. … somewhat mitigated by the construction of partitions on the floor below …
A few weeks before the collapse, the wedding hall owners decided to remove the partitions. … the floor above began to sag several centimetres. The owners viewed the sagging floor primarily as a cosmetic problem, and attempted to level it with additional grout and fill … a new and significant dead load at the weakened area.
"""
People didn’t seem to believe me when I said that hardware engineers have a better time than software engineers.
But think about it: they can and will “start from scratch” whenever they see the need to do so, while software engineers have been forced to cope with bad decisions from the 80s because the cost of starting fresh was simply unaffordable for most projects.
Hardware is not starting from scratch every time. You might think that if you've never worked with hardware, but there are plenty of SDKs out there that support 300 device types from the same extended family with different combinations of ifdefs.
I've been thinking similarly, that we're quickly going to want to start minimising dependencies and code size in the programs we make to try to reduce attack surface area.
That was always little more than unix propaganda. Until GNU came around and held itself to a higher standard, it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing). "Do it well", hardly. A more true to life account of "unix philosophy" is "worse is better". It doesn't have to be good, merely available.
It’s still a relatively decent and ambitious thing to aspire to, i.e. a lean interface/tool scope that prevents scope creep. Composability (with pipelines) also works quite well. But yes, it is somewhat propaganda.
GNU programs do lots of things poorly, starting with "echo -e" and "cat -n" and continuing through to tools like awk and sed. Powershell does Unix philosophy better than GNU does.
> it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing).
You might want to remind yourself what caused the November 2025 Cloudflare outage!
Yeah, well, the Unix philosophy is from the engineering department, not the accounting department.
Funding FOSS projects without advertising, dopamine-hacking, donation-begging into the void, or being subsidized by billionaires that want to influence the electorate is still largely unsolved.
The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
The problem isn't even the billionaires.
The problem is convincing comfortable, ambitious middle-high earners to put a cap on their and their bosses' prospects in exchange for the stability (and subsequent ground preparation for innovation) of a higher floor.
They're the stumbling block because they're the ones who, on balance and en masse, have the money and votng power to excuse and enable the status quo.
> The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
Part of the problem is that there are people who think all rather than only some of those things are a good idea.
High marginal tax rates and taxing unrealized gains are both unintended consequences factories. Especially the second one, but even the first one is basically a trade off between creating perverse incentives and arbitrage opportunities (i.e. massive loopholes) because the high rates don't apply to everything, or supercharging offshoring because the high rates do apply to everything.
Conversely, a UBI is a good idea, and doesn't actually require oppressive tax rates because it replaces most of the existing system of government benefits and subsidies -- which impose even higher de facto marginal tax rates on most of the middle class in the form of benefits phase outs. US federal spending is already >$20,000 per capita.
Not all of that is assistance programs, but a large proportion of it is. And most of those programs are a net negative compared to reallocating their budgets to a UBI. Having separate bureaucracies to administer separate programs for food assistance, housing assistance, education assistance, etc. is foolish even before they create weird marginal rate cliffs and higher marginal rates on lower income people by having arbitrarily overlapping phase out rates.
It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money because you'd save the amount spent on administration, while improving economic efficiency by not imposing arbitrary restrictions on how it's spent. The primary reason we don't do that isn't upper middle class people demanding a status quo in their own interest -- it isn't in their interest.
It's a combination of ordinary incompetence and bad structural incentives because politicians like to claim credit for creating new programs instead of just indexing the amount of a cash payment everybody gets to GDP per capita and then sending them all home.
I get that a lot of folks were traumatised by the shift from init based systems to systemd. However the architecture is sound and relatively straightforward given the inherent complexity in managing a diversity of system processes.
EDITED TO ADD:
If you’re looking for a UNIX anti-hero regarding “do one thing and do it well” (that predates systemd), look no further than emacs.
Most of the complexity comes from trying to wrangle uncooperative, poorly written processes. For example, if process descriptors had existed early enough--they came to Linux long after systemd--process management would have been easier and systemd and alternatives could have had a more narrow focus.
Linux is now a corporate Unix. Many features exist to support tooling around impenetrable services and applications that can't be modified to behave better. This type of value-add is the bread-and-butter of commercial products and services. But by solving problems in the wrong place you're just adding cruft atop cruft, which hastens bitrot. Starting fresh with saner and thinner applications is how Linux won the Unix wars, but now the ecosystem is recapitulating the same sins.
For the problems it's solving systemd is a great system, it's just that the real problems it solves aren't technical, but are rooted in too much layering.
I've taken to saying Donald Knuth was wrong, premature optimization isn't the root of all evil.
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
Man learns how to split code file in two. Man thinks world ending. Man not know up from down, hot from cold. All code: single file! Single file! Single file! Shell is HERESY! libc is HERESY! A user/kernelspace divide is HERESY! Sound abstractions only useful abstractions.
It could push us further into dependency hell though, as people look for a package that does a simple task instead of the risk of expanding their bug/attack surface area, assuming that the library they depend upon has itself been checked (and the same for its dependencies all the way down).
Trying to keep code small could backfire by ballooning dependency on dependencies to do more of the work.
No, adding a "package that does a simple task" and is exposed to untrusted input expands "your bug/attack surface area". It isn't an alternative to "expanding your bug/attack surface area." People who are trying to keep code small will choose 400 lines of their own code that does only what they need instead of 4000 lines of code in a dependency.
>You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable.
So the solutions need to be structural.
e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.
Everything running under seL4 benefits from the guarantees seL4 provides.
The solution needs to be convenient, in practice that trumps security every time. If i need to run my existing apps in Linux VM under seL4, others, fully featured hypervisors will look more enticing.
I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?
This is one of my biggest gripes with systemd. Millions of lines of code. Immense complexity. Constant churn. Endless config changes(leading to outdated and potentially dangerous configs).
Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.
So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".
And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.
I do not believe that it is possible for SysVInit itself to have any problems on laptops, because it does nothing that is hardware specific.
Since 2005, for more than 2 decades, I have used on all my laptops only Linux with Gentoo and SysVInit and I have never encountered any problem.
Perhaps you mean that your particular Linux distribution had some startup shell scripts (which are not a part of SysVinit, they are only launched by SysVInit when the run level is changed) that were buggy on laptops. Buggy initialization shell scripts are not unusual, but such scripts are normally small and any bugs are relatively easy to find and fix, unlike with the bugs of SystemD.
While you did not had any single problem with SystemD, when I first tried SystemD (with Arch Linux; that was many years ago and that specific bug must have been fixed some time later, but nonetheless it convinced me that the developers of SystemD are incompetent), SystemD exhibited the most stupid bug that I have ever seen in a computer, i.e. the shutdown of the computer was very slow in comparison with SysVInit and moreover it sometimes failed, which is a thing that I have never seen in a computer elsewhere.
The reason for failure was that SystemD, instead of just sending signals to all processes like SysVInit, it used some inter-process messaging through DBus. At that time, at least on my computer, there was some kind of race condition between the concurrent processes that were terminated and some times DBus died before some other process that tried to communicate through it and then the SystemD shutdown sequence remained stuck and it never completed.
I consider such a bug much worse than a bug caused by carelessness, like a buffer overflow, because it demonstrated an erroneous design of the architecture of the system.
But that's not quite the the right comparison, is it?
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.
But is the actual architecture of systemd giving simple, securable, reviewable boundaries? This is a codebase that runs in stages of inherent privelege and very low levels in many linux systems.
Yes, systemd is not one piece of software, it’s a collection of software, like GNU. The components aren’t just modules or something, they’re actually different programs altogether.
When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.
Sysvinit is not 1000 lines if you add all the scripts you have to write to get feature parity with systemd. And now you have written that in the worst programming language ever created, bash, that is basically impossible to not be chock full of errors.
Frankly the amount of crying I have seen about systemd... and it's basically the most stable part of my Linux installs. Even though I really have seen everything else "catch on fire".
Even daemontools (0.76-8.1 Debian) is 3771 lines of C, much more than 1000. Sysvinit is much more code than daemontools; sysvinit 3.06 is 8407 lines of C and 3595 lines of sh, according to David A. Wheeler's 'SLOCCount'. systemd 252.39 is 549427 lines of C, 26257 lines of Python, 18735 lines of sh, etc., not even counting its dozen or so dependencies.
So you're correct that sysvinit is more than an order of magnitude smaller and simpler than systemd, and having all that code in your TCB is an express ticket to the bug-of-the-month club. But you're still underestimating sysvinit by an order of magnitude.
Bringing Treacherous Computing to Linux is, of course, generally a bad thing, and it's not a good idea to have the lead maintainer of the central component of your operating system employed by a notoriously unethical company whose main product is a competing operating system.
Sysvinit systems don't actually use sysvinit though, they just use sysvinit to kick off a complicated set of shell scripts on boot. The real boot code is in the shell scripts and the shell.
Usually your inittab only includes gettys, shutdown/reboot, and launching rc. That's the only things sysvinit does and it's not even the best way to do them.
A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.
BIOS is massive. It implements a ton of interfaces that nobody cares about any more but they have to be there for compatibility, so vendors just shove in some code modules someone else wrote and hope for the best. Nobody writes their BIOS from scratch because it wouldn't run something and someone would certainly complain, and there's no benefit to it. And to top it off you've got this weird execution environment that nobody has the right toolchains for unless you buy them.
You cannot trust compiler generated machine code and/or significantly sized runtimes. Some simple binary specifications with some assembly implementations (could be on several ISAs, x86_64, RISC-V, etc).
"Popular" usually means that supporting many use cases. Many use cases means a lot of code. Probably means increased complexity. Tailored hyperspecific firmware is much more usable now and maybe you can even formally verify it.
I feel like I was reading this from Marcus Ranum in 2005 in the famous article "Six dumbest ideas in computer security"[1] where he wrote about just running a custom webserver that accepts only correctly specified requests, instead of Apache and a filter set of bad-request-blockers and a default-permit firewall and etc.
That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.
I'm not sure we have been living the dream with shitty desktop web apps running in a full browser each taking several gigs of ram for playing some music or chatting with coworkers and friends. Electron and its likes are the scourge of software world.
I'm happy if LLMs and the semiconductor shortage will create a renaissance of native applications.
The core of the problem is a profit incentive and an economy based on greed. Our society is designed to extract value, not to offer the best products/services to the general population.
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.
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.
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.
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.
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.
> 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?
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.
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)
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
It's good from the hardware designer's perspective since less things are their problem. It's bad for the software creator since more things are their problem, and for the user since it's hard to find compatible software for their hardware.
It's also the normal way the entire history of computers has always worked, except for the IBM PC and its derivatives. If you want to install an OS on a 2025 OnePlus Blahdy Blahdy Blah you need to find an OS explicitly built for a 2025 OnePlus Blahdy Blahdy Blah - one for a 2025 OnePlus Blahdy Blahdy or for a 2026 Blahdy Blahdy Blah will not work and will likely just brick your phone. And nobody is out there building every OS for every phone model. But I can install Linux built for a Lenovo laptop onto a Dell desktop or a SuperMicro server.
We are in agreement that phones (and embedded devices in general) are worse. My claim is that they are worse because UEFI is too fucking complicated to implement, so nobody bothered. Which resulted in linux being built with the hardware descriptor table for the device in question, itself implemented by the vendor and published (and eventually merged upstream) due to gpl restrictions. It's also not uncommon for the 2026 edition to use a completely different SoC than the 2025 version (as in different vendor and even CPU arch) - routers even do this for the same model with a different hardware revision.
As to your other point, software is always easier to change than hardware, even if easy means hooking up a ch341a chip. Hardware however always transitions from sand to electron prison to rock to sand.
If you used a standard UEFI interface you'd either imprison the OS within the UEFI using UEFI interfaces to hardware, or you'd imprison it within an inaccurate hardware description (either DT or ACPI) that it would be forced to adhere to. The current situation is complete OS freedom (except for TrustZone and secure boot) but it turns out that isn't actually what we wanted.
> 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").
"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.
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.
> 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.
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.
> 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.
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.
> 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.
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
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.
So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
What we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.
For a deployed server, yes, you’d probably need to first get inside their network, then using some other exploit or social engineering, cause the server to reboot and then provoke this vulnerability and gain a persistent shell on the server.
This may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?
There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?
So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting.
Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies.
For client devices who PXE boot (rare) and also are on Ethernet during boot (basically desktops and docked laptops) and also reachable by pings (so the attacker needs to be inside the network).
Some networks carry ICMP through untouched. Why you'd be using public addresses for your systems between DHCP and PXE boot is beyond me, but it's possible. However, someone would need to spray and pray because they wouldn't have visibility within the network to know about the DHCP and PXE traffic actually happening at that time.
If you're on the same LAN segment, you can probably see the DHCPDISCOVER messages that the UEFI would send as part of the PXE boot process. I would guess that you could also tell the difference between a DHCP request from UEFI vs one from Linux/Windows.
Given, without any network level DHCP guard configuration, you could likely also send your own DHCPOFFER and just tell it to PXE-boot your own image :) I suppose for some trusted-boot threat scenarios code execution at the UEFI level is a bigger issue. No idea how modern UEFI PXE-boot deals with signed images.
Before publishing the exploit, I imagine it would've been quite practical to flood an entire data center with malicious ICMP packages and just waiting for the next kernel patches that necessitate rebooting to come out. If you don't know that the ICMP packets flooding in aren't just weird background noise, you might ignore them when they're not causing problems.
If I send a load of ICMP at a datacenter, don't they just get dealt with at the firewall, not by individual servers? Like I can't ping a specific machine inside a datacenter, it just pings the datacenter itself
Depends on how the datacenter deals with ICMP. If you host dedicated machines on dedicated IP addresses, there's no need to deal with traffic rewriting and you can just use ICMP the normal way. If you apply NAT or weird filtering then you'll hit the firewall first of course.
PXE boot enabled and attempted by default on an internet-facing network interface is certainly a... choice.
This is something that shouldn't be possible in the real world because any sysadmin should know not to do this, but guaranteed there are at least some small time operations with a couple of colo'd servers that only have single interfaces serving public traffic, and the intern who set them up didn't know what a boot order was or what "PXE" even did.
> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.
This one seems weird. PXE-boot is such a fragile process in and off itself this doesn't strike me as end-of-the-world. If an attacker has enough presence on your network to send a targeted ICMP packet, they almost certainly could also fool around with your PXE-booting servers some other way.
It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.
Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.
Yeah I'm actually not terribly worried about the server scenario, but having a way to get code exec in the firmware lets you defeat measured boot, which means this is a Bitlocker bypass in the default config.
Would this mean any TPM based decryption keys could potentially be compromised in this kind of attack? E.g. when they're used for LUKS disk encryption.
Yes - all the times I've seen PXE boot used, the usage has been "Hold F12 during boot to reformat the disk and re-install the OS from scratch"
Which is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
Some thin clients boot from PXE so they can forego local storage completely. Being able to update the entire fleet and completely prevent any kind of local changes with a simple reboot is a gamechanger for maintainability: you can be 100% certain that every "installation" is absolutely identical.
It also wasn't uncommon to install a server's hypervisor to a USB flash drive, or a tiny local SSD. Server motherboards with internal USB-A ports (not headers, the entire port) were quite common, and there were even IDE flash drives you could plug straight into the motherboard. This allowed you to completely dedicate the regular storage to the client VMs. I would not be surprised if that same market also used PXE for the same reason in larger installations.
PXE can be great for stacks of virtual machines or thin client setups.
PXE has been enabled by default on most devices I bought, but only after USB and SSD boot failed, so in practice it's not really something you're going to see a lot of.
If such an ICMP error message comes from outside, the firewalls with stricter rules will reject it, because it does not correspond to packets sent by the victim computer.
Moreover, Ethernet booting is done usually from separate management networks to which only the administrators are connected, on which also other vulnerable protocols, like IPMI, are used, not from the main network that may have an Internet gateway.
An interesting part of this is actually in defeating secure-boot or bitlocker. If a device is misconfigured for PXE boot with an otherwise locked down UEFI system, and strong secure boot. This could let you break the boot-chain and then disable secure-boot or extract keys from a TPM.
The main question here is how often devices you'd want to try this against have PXE boot enabled. I'm thinking of locked down laptops mostly. Either corporate laptops, or manufacturer locked-down devices (chromebooks, I think some microsoft surfaces).
Servers are locked down these days too, are they not? They may have an encrypted boot image, with keys in TPM, and boot from a PXE provisioning system. Would this offer a path to modify that boot image?
How exploitable is this really? First, the machine has to do a PXE boot. In almost EVERY machine I have set up, it boots from fixed media first. Second, you have for force a machine reboot, and the machine has to be on a network you can reach.
Sure, there are lots of machines that PXE boot, but if it's on a public facing machine, why would you even configure it to PXE boot?
Arguably it's trivial to fix for most netbooting environments, the one iffy case would be corporate laptops configured to boot from net for management purposes because there "attacker controls the network and timing" suddenly can become easy
It's ICMP, so any network that doesn't filter ICMP and would allow malformed packets through could be a target. You'd have no idea when something was PXE booting, so you'd have to keep sending the packets and wait.
A bigger question I think is why you'd assign a public IP to a machine for PXE boot rather than booting it from a private IP space then assigning any publics once the OS is booted.
The PHP CVS were originally reported as perfect 10s and in theory allow remote access (practically all of the internet). This requires physical hardware access (practically 0 of the internet).
Those original PHP 10s were negotiated down into a 9.2 by disclosure.. so maybe this'll be an 8.7 soon.
Well because some php configurations had an absurdly low default max upload size, which made the rce way harder.
Plesk for example ships with 2m for some reason.
The fact that a subset of systems are in a less vulnerable configuration doesn't have any bearing on the CVSS score.
> Specific configurations should not impact any attribute contributing to the CVSS Base metric assessment , i.e., if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration. [1]
For a vulnerability to score a 10 its Attack Complexity must be 'Low' (broadly speaking: it doesn't require target-specific customizations or mitigations [1]), which isn't the case with php2shell.
CVSS is an imperfect system. Most of the time it gets the idea of how severe an issue is across, but once you go above an 8, maybe an 8.5, there are some perverse incentives at play. Even with newer versions of the framework coming out over the years, there have always been gaps.
Even before AI, there was prestige in being able to say that you (or your team) found a 9.2 in some major piece of software. You could put that on your resume in some specializations.
Now with AI vulnerability scanning being so hyper-commercialized (but not yet fully commoditized), this is cranked way up since there are more monied interests involved, and many of them are probably trying to make a quick buck before LLM-based vulnerability scans are a commodity (for better or worse).
If you have network boot enabled and you’re on a recent enough uefi you’re vulnerable yes. However personal devices have uefi network boot disabled by default
I swear I have seen plenty of PCs attempt a PXE boot before failing and continuing on to the next boot option. It probably isn't the default for most "personal" machines but... That's not really a guarantee I would want to hang my hat on...
They had a massive amount of bot attacks recently. That captcha wasn’t always there, but the website became so slow as to be unusable. That captcha only surfaces from certain countries. It comes up far, far less frequently than it did a few weeks ago
doesn't it also threatens most servers currently not on planet earth? like on chinas space station? i guess ISS's hardware is too old and UEFI didn't exist back then, so they are probably safe.
http2shell and php2shell are both really difficult to exploit. Not that they aren't serious (and should be patched), but it's not the doomsday scenario that the news makes it out to be.
As TFA says, this can be exploited only by someone who already has access to the internal network of the company.
Moreover, in well configured networks there is typically a separate network for the management Ethernet interfaces of the servers, to which non-authorized computers do not have access, and Ethernet booting of the servers is done through that network.
So the bug can be exploited only by a company insider, who must be an admin for the case with a separated management network, or by an external attacker who already has control over an internal computer, which must be the computer of an admin in the case with separate management network.
so how many firmwares actually compile in this ICMP stuff? because edk2 builds in a way that it will only package the stuff actually used. u include protocola and handles etc.
personally never found a reason why to include icmp in there for what i was building using edk2.
as others noted pxe is also already very fragile and enough network access to perform the icmp attack is likely enough access to mitm the entire pxe run and slap in your own boot image or modules etc.
i dont think most servers boot using PXE so that is grossly overstated? or would it include the attacker going into the boot menu and selecting to pxe boot... because why use an exploit then if you can just point it to your own server and again pull the image like that.
all u need is a konboot or similar tool inserted to then subsequently load the original image -_-
Suppose the server only boots signed images created by itself, which the PXE server happens to serve. You cannot just switch or mess with the menu. But if you can exploit the boot chain before any Secure Boot components run, then you might find your way in.
Several large bare-metal hosting companies. Not over the open Internet, but that doesn't matter if the management networks are shared and the price of admission a single server rental.
I would be concerned for e.g. Hetzner dedicated servers. They assumedly PXE-boot consumer grade UEFI hardware that is unlikely to have a dedicated management interface. Exploitability would depend on how well they filter ICMP within their network.
It's a pretty common setup on servers, even if it's not the majority. Probably more commonly it's part of the boot sequence on servers even if it's not used. I would say this is a relevant issue for most organizations' network security because of the risk it represents of being able to escalate from compromising a less privileged machine (e.g. a user's device) to a more privileged machine. It's not a 'oh god every server is going to be pwned' issue, but it doesn't need to be to be worth alerting people to.
It's always fearmongering when it comes to "vulnerabilities" that affect the model of locking down computing devices.
This shit used to confuse me so hard when I was learning security. It seemed that articles were talking about something really important, but I just couldn't connect it to anything I knew. Then I realized they weren't talking about security for users, but rather security from users - and for entities ultimately looking to restrict users (the same inversion-of-authority as TSA propaganda). Hence the syndrome of acronym hell, as that amount of overabstraction is required to motivate a system for its own purposes.
Now given that this is a network exploit, you've got to adapt my model a bit from above - my framing is most clear when talking about local "exploits" in locked down bootloaders etc. But from an individual security perspective here? If you've disabled the network stack in your BIOS (because why the hell is it there in the first place), OR put any management interfaces on their own network unreachable from anything that isn't trusted to be managing, this is an utter nothingburger.
We recently wrote about moving away from OVMF (~1M lines of C) to very minimal and hyperspecific firmware (300 lines of assembly)[1] for our specific confidential VM machine targets, and the idea that "popular" does not automatically mean "secure". You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable. You can instead just write hyperspecific, small codebases and throw all the security practices at it - like LLMs (economical if it's small), fuzzing, formal methods etc.
[1] https://tinfoil.sh/blog/2026-10-25-less-is-more
Yea I really like this idea.
We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.
When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.
Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.
> “I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way”
See the Versailles Wedding Hall collapse in Israel, 2001: https://en.wikipedia.org/wiki/Versailles_wedding_hall_disast...
""" An initial inquiry blamed the collapse on the Pal-Kal method of constructing light-weight coffered concrete floor systems which was banned shortly after …
Late in the construction process … a third storey was added. … the structure supporting the new third storey was subjected to much greater loading than was originally anticipated. … somewhat mitigated by the construction of partitions on the floor below …
A few weeks before the collapse, the wedding hall owners decided to remove the partitions. … the floor above began to sag several centimetres. The owners viewed the sagging floor primarily as a cosmetic problem, and attempted to level it with additional grout and fill … a new and significant dead load at the weakened area. """
People didn’t seem to believe me when I said that hardware engineers have a better time than software engineers.
But think about it: they can and will “start from scratch” whenever they see the need to do so, while software engineers have been forced to cope with bad decisions from the 80s because the cost of starting fresh was simply unaffordable for most projects.
Unless they work at Intel or AMD...
Hardware is not starting from scratch every time. You might think that if you've never worked with hardware, but there are plenty of SDKs out there that support 300 device types from the same extended family with different combinations of ifdefs.
To be fair, the misery of software developers is often directly attributable to the decisions of hardware engineers.
I've been thinking similarly, that we're quickly going to want to start minimising dependencies and code size in the programs we make to try to reduce attack surface area.
Do one thing, and do it well.
The unix philosophy prevails!
That was always little more than unix propaganda. Until GNU came around and held itself to a higher standard, it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing). "Do it well", hardly. A more true to life account of "unix philosophy" is "worse is better". It doesn't have to be good, merely available.
It’s still a relatively decent and ambitious thing to aspire to, i.e. a lean interface/tool scope that prevents scope creep. Composability (with pipelines) also works quite well. But yes, it is somewhat propaganda.
A lean interface needs to have incredibly well-specified behaviour to not be a pain in the ass to work with.
GNU reimplementations showed up late enough not to care about running in a 64K address space.
GNU programs do lots of things poorly, starting with "echo -e" and "cat -n" and continuing through to tools like awk and sed. Powershell does Unix philosophy better than GNU does.
> it was common for unix tools to do bullshit like read input into fixed length line buffers and silently truncate anything longer (when they weren't overtly crashing).
You might want to remind yourself what caused the November 2025 Cloudflare outage!
Until you link against xz
Yeah, well, the Unix philosophy is from the engineering department, not the accounting department.
Funding FOSS projects without advertising, dopamine-hacking, donation-begging into the void, or being subsidized by billionaires that want to influence the electorate is still largely unsolved.
The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
The problem isn't even the billionaires.
The problem is convincing comfortable, ambitious middle-high earners to put a cap on their and their bosses' prospects in exchange for the stability (and subsequent ground preparation for innovation) of a higher floor.
They're the stumbling block because they're the ones who, on balance and en masse, have the money and votng power to excuse and enable the status quo.
> The problem isn't that we don't know how (solved issue: UBI, higher pay for less work, high marginal income tax rate, unrealized capital gains tax above a minimum, land tax, etc.).
Part of the problem is that there are people who think all rather than only some of those things are a good idea.
High marginal tax rates and taxing unrealized gains are both unintended consequences factories. Especially the second one, but even the first one is basically a trade off between creating perverse incentives and arbitrage opportunities (i.e. massive loopholes) because the high rates don't apply to everything, or supercharging offshoring because the high rates do apply to everything.
Conversely, a UBI is a good idea, and doesn't actually require oppressive tax rates because it replaces most of the existing system of government benefits and subsidies -- which impose even higher de facto marginal tax rates on most of the middle class in the form of benefits phase outs. US federal spending is already >$20,000 per capita.
Not all of that is assistance programs, but a large proportion of it is. And most of those programs are a net negative compared to reallocating their budgets to a UBI. Having separate bureaucracies to administer separate programs for food assistance, housing assistance, education assistance, etc. is foolish even before they create weird marginal rate cliffs and higher marginal rates on lower income people by having arbitrarily overlapping phase out rates.
It isn't about the source of the money. Converting those things to a UBI would cost less money to give people more money because you'd save the amount spent on administration, while improving economic efficiency by not imposing arbitrary restrictions on how it's spent. The primary reason we don't do that isn't upper middle class people demanding a status quo in their own interest -- it isn't in their interest.
It's a combination of ordinary incompetence and bad structural incentives because politicians like to claim credit for creating new programs instead of just indexing the amount of a cash payment everybody gets to GDP per capita and then sending them all home.
I feel quite comfortable asserting that anything involving systemd is no longer associated with the Unix philosophy
I get that a lot of folks were traumatised by the shift from init based systems to systemd. However the architecture is sound and relatively straightforward given the inherent complexity in managing a diversity of system processes.
EDITED TO ADD: If you’re looking for a UNIX anti-hero regarding “do one thing and do it well” (that predates systemd), look no further than emacs.
Most of the complexity comes from trying to wrangle uncooperative, poorly written processes. For example, if process descriptors had existed early enough--they came to Linux long after systemd--process management would have been easier and systemd and alternatives could have had a more narrow focus.
Linux is now a corporate Unix. Many features exist to support tooling around impenetrable services and applications that can't be modified to behave better. This type of value-add is the bread-and-butter of commercial products and services. But by solving problems in the wrong place you're just adding cruft atop cruft, which hastens bitrot. Starting fresh with saner and thinner applications is how Linux won the Unix wars, but now the ecosystem is recapitulating the same sins.
For the problems it's solving systemd is a great system, it's just that the real problems it solves aren't technical, but are rooted in too much layering.
Ah the famous book quote, never seen in practice on real UNIX systems.
I've taken to saying Donald Knuth was wrong, premature optimization isn't the root of all evil.
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
Man learns how to split code file in two. Man thinks world ending. Man not know up from down, hot from cold. All code: single file! Single file! Single file! Shell is HERESY! libc is HERESY! A user/kernelspace divide is HERESY! Sound abstractions only useful abstractions.
When Knuth wrote that, I don't think dependencies as we think of them today existed. Libraries were few and solved specialized, difficult problems.
It could push us further into dependency hell though, as people look for a package that does a simple task instead of the risk of expanding their bug/attack surface area, assuming that the library they depend upon has itself been checked (and the same for its dependencies all the way down).
Trying to keep code small could backfire by ballooning dependency on dependencies to do more of the work.
When op talks of keeping code small I’m pretty sure they’re talking about all code including dependencies.
No, adding a "package that does a simple task" and is exposed to untrusted input expands "your bug/attack surface area". It isn't an alternative to "expanding your bug/attack surface area." People who are trying to keep code small will choose 400 lines of their own code that does only what they need instead of 4000 lines of code in a dependency.
This is the year of microkernels.
Unikernels and beyond, really. The future is small, single-purpose programs running on virtualized bare metal with minimal library dependencies.
Screw dependencies, write your own. Software is cheap and fast now. No need to depend on someone else’s code as a possible attack vector.
>You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable.
So the solutions need to be structural.
e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.
Everything running under seL4 benefits from the guarantees seL4 provides.
The solution needs to be convenient, in practice that trumps security every time. If i need to run my existing apps in Linux VM under seL4, others, fully featured hypervisors will look more enticing.
Genode appears to be very convenient if you are looking into a way to run microkernels for general purpose computing.
You still have to draw the rest of the owl though. A proven secure starting point is neat but it's not actually the system you want to build.
I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?
This is one of my biggest gripes with systemd. Millions of lines of code. Immense complexity. Constant churn. Endless config changes(leading to outdated and potentially dangerous configs).
Sysvinit, it's a 1000 lines of code, maybe a bit more. It's a rock compared to systemd.
So many devs have zero issue with large codebases. Some substitute "small" with "perceived small because I pull in 10M lines of node and composer packages".
And of course the new goal is to bring "trusted computing", eg Microsoft style EEE to Linux with Lennart's now corporate gig.
But it is a different world. So, what can you do?
> It's a rock compared to systemd.
Complete opposite of my experience. I've never had a single problem with SystemD - it's one of the most surprisingly reliable parts of Linux IMO.
In contrast SysVInit worked ok on servers and sort of on desktops, but on laptops forget it.
I do not believe that it is possible for SysVInit itself to have any problems on laptops, because it does nothing that is hardware specific.
Since 2005, for more than 2 decades, I have used on all my laptops only Linux with Gentoo and SysVInit and I have never encountered any problem.
Perhaps you mean that your particular Linux distribution had some startup shell scripts (which are not a part of SysVinit, they are only launched by SysVInit when the run level is changed) that were buggy on laptops. Buggy initialization shell scripts are not unusual, but such scripts are normally small and any bugs are relatively easy to find and fix, unlike with the bugs of SystemD.
While you did not had any single problem with SystemD, when I first tried SystemD (with Arch Linux; that was many years ago and that specific bug must have been fixed some time later, but nonetheless it convinced me that the developers of SystemD are incompetent), SystemD exhibited the most stupid bug that I have ever seen in a computer, i.e. the shutdown of the computer was very slow in comparison with SysVInit and moreover it sometimes failed, which is a thing that I have never seen in a computer elsewhere.
The reason for failure was that SystemD, instead of just sending signals to all processes like SysVInit, it used some inter-process messaging through DBus. At that time, at least on my computer, there was some kind of race condition between the concurrent processes that were terminated and some times DBus died before some other process that tried to communicate through it and then the SystemD shutdown sequence remained stuck and it never completed.
I consider such a bug much worse than a bug caused by carelessness, like a buffer overflow, because it demonstrated an erroneous design of the architecture of the system.
> Buggy initialization shell scripts are not unusual
You can't really separate the buggy SysVinit shell scripts from SysVinit itself. That's classic "guns don't kill people, people kill people".
I prefer to not get shot.
On Gentoo aren't you using OpenRC?
But that's not quite the the right comparison, is it?
Systemd doesn't just replace 1000 lines of Sysvinit. Those "millions of lines" also replace the thousands of hundred-line poorly-vetted Bash scripts you need, plus your syslog daemon, plus dozens of "fork, setuid, chroot" variants, plus your cron daemon. And that's before we get into things not directly related to service management, like logind, hostnamed, networkd, resolved, timesyncd, tmpfiles, udevd, and so on.
Systemd is an umbrella project. Look at each individual component in isolation, and the vast majority of the time the thing it replaces is significantly more complex and fragile. Systemd was adopted by most of the Linux ecosystem because it was a significant improvement over the status quo, there is no need to invent conspiracy theories here.
But is the actual architecture of systemd giving simple, securable, reviewable boundaries? This is a codebase that runs in stages of inherent privelege and very low levels in many linux systems.
Well, my only gripe with it is that it's C. Otherwise it's very modular.
Yes, systemd is not one piece of software, it’s a collection of software, like GNU. The components aren’t just modules or something, they’re actually different programs altogether.
When people say systemd they really mean systemd-init, which is one piece of software. Not systemd-resolved, which is another.
The number of binaries installed on the system has little to do with how the software is developed - how many pieces of software is LibreOffice?
Sysvinit is not 1000 lines if you add all the scripts you have to write to get feature parity with systemd. And now you have written that in the worst programming language ever created, bash, that is basically impossible to not be chock full of errors.
Frankly the amount of crying I have seen about systemd... and it's basically the most stable part of my Linux installs. Even though I really have seen everything else "catch on fire".
Even daemontools (0.76-8.1 Debian) is 3771 lines of C, much more than 1000. Sysvinit is much more code than daemontools; sysvinit 3.06 is 8407 lines of C and 3595 lines of sh, according to David A. Wheeler's 'SLOCCount'. systemd 252.39 is 549427 lines of C, 26257 lines of Python, 18735 lines of sh, etc., not even counting its dozen or so dependencies.
So you're correct that sysvinit is more than an order of magnitude smaller and simpler than systemd, and having all that code in your TCB is an express ticket to the bug-of-the-month club. But you're still underestimating sysvinit by an order of magnitude.
Bringing Treacherous Computing to Linux is, of course, generally a bad thing, and it's not a good idea to have the lead maintainer of the central component of your operating system employed by a notoriously unethical company whose main product is a competing operating system.
Sysvinit systems don't actually use sysvinit though, they just use sysvinit to kick off a complicated set of shell scripts on boot. The real boot code is in the shell scripts and the shell.
Usually your inittab only includes gettys, shutdown/reboot, and launching rc. That's the only things sysvinit does and it's not even the best way to do them.
> So, what can you do?
A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.
> to very minimal and hyperspecific firmware (300 lines of assembly)
So, just normal BIOS boot?
BIOS is massive. It implements a ton of interfaces that nobody cares about any more but they have to be there for compatibility, so vendors just shove in some code modules someone else wrote and hope for the best. Nobody writes their BIOS from scratch because it wouldn't run something and someone would certainly complain, and there's no benefit to it. And to top it off you've got this weird execution environment that nobody has the right toolchains for unless you buy them.
You cannot trust compiler generated machine code and/or significantly sized runtimes. Some simple binary specifications with some assembly implementations (could be on several ISAs, x86_64, RISC-V, etc).
I guess this is what they are doing.
"Popular" usually means that supporting many use cases. Many use cases means a lot of code. Probably means increased complexity. Tailored hyperspecific firmware is much more usable now and maybe you can even formally verify it.
> Tailored hyperspecific firmware is much more usable now
"Now"? It's always been that way. Most developers just didn't want to admit it because it meant more work and that their past existing work was shite.
> admit it because it meant more work and that their past existing work was shite.
And that is why it is now more usable. More affordable.
> Most developers just didn't want to admit it because it meant more work
Sounds like it wasn't very usable
I feel like I was reading this from Marcus Ranum in 2005 in the famous article "Six dumbest ideas in computer security"[1] where he wrote about just running a custom webserver that accepts only correctly specified requests, instead of Apache and a filter set of bad-request-blockers and a default-permit firewall and etc.
That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.
[1] https://www.ranum.com/security/computer_security/editorials/...
70's software is closed-source bespoke reimplementation; 80's Dream of reusable software components; 90's Building the Dream; 00's Living the Dream; 10's Everything is amazing but; 20's transition to...; 30's what??? Open-{source, reference implementation, tests, specs, design docs, gist, ...?} bespoke reimplementation?
中国特色. And an even larger gap vis optimized-for-pharma US IP config (Industrial Policy).
I'm not sure we have been living the dream with shitty desktop web apps running in a full browser each taking several gigs of ram for playing some music or chatting with coworkers and friends. Electron and its likes are the scourge of software world.
I'm happy if LLMs and the semiconductor shortage will create a renaissance of native applications.
Javascript and people doing things with it that they shouldn't is at the core of the problem.
If it wasn't JavaScript it would be something else. What's the slowest machine on this list? https://danluu.com/input-lag/
The core of the problem is a profit incentive and an economy based on greed. Our society is designed to extract value, not to offer the best products/services to the general population.
> https://tinfoil.sh/blog/2026-10-25-less-is-more
The blog-post is written by AI. I am more than interested to hear a human talk about it but AI generated blog post removes that interest.
Dan Goodin is listed as the author on the Ars Technica article.
Sorry but I wasn't talking about the Ars Technica article but the article that GP had shared that I had highligted under >
The article that I am talking about which is generated by AI is this one: https://tinfoil.sh/blog/2026-10-25-less-is-more
Hope this clears up the confusion!
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.
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.
I think uboot is kinda doing that?
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.
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.
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.
How should it be solved instead?
BIOS had ACPI, too, so I'm not sure how it contributes to the argument.
some arm64 sbcs support edk2/uefi btw. I make sure I just use those. Look for "Arm SystemReady" certification, which requires this
Any chance you could recommend a board or two?
> 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?
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?
bro you responding to Matthew Garret. I don't want to defend either of you two but you set the bar pretty low.
Apparently that's someone mildly important, for anyone else who's never heard of him https://en.wikipedia.org/wiki/Matthew_Garrett
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.
https://www.logicallyfallacious.com/logicalfallacies/Appeal-...
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)
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
It's good from the hardware designer's perspective since less things are their problem. It's bad for the software creator since more things are their problem, and for the user since it's hard to find compatible software for their hardware.
It's also the normal way the entire history of computers has always worked, except for the IBM PC and its derivatives. If you want to install an OS on a 2025 OnePlus Blahdy Blahdy Blah you need to find an OS explicitly built for a 2025 OnePlus Blahdy Blahdy Blah - one for a 2025 OnePlus Blahdy Blahdy or for a 2026 Blahdy Blahdy Blah will not work and will likely just brick your phone. And nobody is out there building every OS for every phone model. But I can install Linux built for a Lenovo laptop onto a Dell desktop or a SuperMicro server.
We are in agreement that phones (and embedded devices in general) are worse. My claim is that they are worse because UEFI is too fucking complicated to implement, so nobody bothered. Which resulted in linux being built with the hardware descriptor table for the device in question, itself implemented by the vendor and published (and eventually merged upstream) due to gpl restrictions. It's also not uncommon for the 2026 edition to use a completely different SoC than the 2025 version (as in different vendor and even CPU arch) - routers even do this for the same model with a different hardware revision.
As to your other point, software is always easier to change than hardware, even if easy means hooking up a ch341a chip. Hardware however always transitions from sand to electron prison to rock to sand.
If you used a standard UEFI interface you'd either imprison the OS within the UEFI using UEFI interfaces to hardware, or you'd imprison it within an inaccurate hardware description (either DT or ACPI) that it would be forced to adhere to. The current situation is complete OS freedom (except for TrustZone and secure boot) but it turns out that isn't actually what we wanted.
> 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").
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.
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.
"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.
> 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.
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.
> 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.
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.
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.
> 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.
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.
> 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.
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
> 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.
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.
So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
You can technically send then all the time and it is enough that they boot once. No need to know the time beforehand.
At least some enterprise IDS /AFW could presumably have a signature configured for this traffic scenario.
Before you manually configure a rule in your WAF you might as well just fix the vulnerability in the vulnerable component directly ^^
especially in free/open source software like edk2
The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
What we _can_ do, though, while the OS is running is detecting that bogus large ICMP packets are sent continuously. At least, this would be early warning that a reboot may be risky without disabling PXE.
If you want to filter this, you should probably do that at the network level, not the host level. Ideally at switches, otherwise with firewalls.
I mean yeah, but who is letting unfiltered ICMP onto a production network?
What filters do you recommend? ICMP is pretty important and many networks have been broken by setting the wrong filters.
For a deployed server, yes, you’d probably need to first get inside their network, then using some other exploit or social engineering, cause the server to reboot and then provoke this vulnerability and gain a persistent shell on the server.
This may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?
There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?
It its anything like recent exploits, the whole internet is going to get hacked in 15 minutes... its a real exploit didn't you know?
The chaining to get something like this to work is pretty up there.
Send an ICMP packet while it is booting from PXE.
So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting.
Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies.
For client devices who PXE boot (rare) and also are on Ethernet during boot (basically desktops and docked laptops) and also reachable by pings (so the attacker needs to be inside the network).
Some networks carry ICMP through untouched. Why you'd be using public addresses for your systems between DHCP and PXE boot is beyond me, but it's possible. However, someone would need to spray and pray because they wouldn't have visibility within the network to know about the DHCP and PXE traffic actually happening at that time.
If you're on the same LAN segment, you can probably see the DHCPDISCOVER messages that the UEFI would send as part of the PXE boot process. I would guess that you could also tell the difference between a DHCP request from UEFI vs one from Linux/Windows.
Given, without any network level DHCP guard configuration, you could likely also send your own DHCPOFFER and just tell it to PXE-boot your own image :) I suppose for some trusted-boot threat scenarios code execution at the UEFI level is a bigger issue. No idea how modern UEFI PXE-boot deals with signed images.
If you're on the same LAN segment you can just serve a malicious boot image, no need for exploits.
Before publishing the exploit, I imagine it would've been quite practical to flood an entire data center with malicious ICMP packages and just waiting for the next kernel patches that necessitate rebooting to come out. If you don't know that the ICMP packets flooding in aren't just weird background noise, you might ignore them when they're not causing problems.
If I send a load of ICMP at a datacenter, don't they just get dealt with at the firewall, not by individual servers? Like I can't ping a specific machine inside a datacenter, it just pings the datacenter itself
Depends on how the datacenter deals with ICMP. If you host dedicated machines on dedicated IP addresses, there's no need to deal with traffic rewriting and you can just use ICMP the normal way. If you apply NAT or weird filtering then you'll hit the firewall first of course.
What if the ICMP packets are coming from inside the datacenter?
Consider a shared or cloud hosting scenario for example.
PXE boot enabled and attempted by default on an internet-facing network interface is certainly a... choice.
This is something that shouldn't be possible in the real world because any sysadmin should know not to do this, but guaranteed there are at least some small time operations with a couple of colo'd servers that only have single interfaces serving public traffic, and the intern who set them up didn't know what a boot order was or what "PXE" even did.
* but only if you have local network access while they're trying to network boot
Seems a bit overblown, couldn't you just serve a malicious boot image anyway?
> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.
This one seems weird. PXE-boot is such a fragile process in and off itself this doesn't strike me as end-of-the-world. If an attacker has enough presence on your network to send a targeted ICMP packet, they almost certainly could also fool around with your PXE-booting servers some other way.
Yeah but that just lets them replace the OS that gets booted.
This gives the attacker access at the UEFI level and above -- they can use it to produce false attestations.
Do any of the locked down consoles or phones use a vulnerable UEFI implementation by any chance?
Phones most commonly use their own bootloader stack.
UEFI is pretty common on phones now, but it's unlikely that any of them are running this network stack there.
Is it? I'd like a UEFI phone booting GNU/Linux but last I looked it was a bunch of hacky aftermarket firmwares.
PS your profile links a blog that says you moved
It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.
And thanks! Updated my profile.
Exactly. No phones have PXE boot enabled, regardless of the rest.
Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.
Yeah I'm actually not terribly worried about the server scenario, but having a way to get code exec in the firmware lets you defeat measured boot, which means this is a Bitlocker bypass in the default config.
Would this mean any TPM based decryption keys could potentially be compromised in this kind of attack? E.g. when they're used for LUKS disk encryption.
Yup, if there's no passphrase involved.
Even if there is a passphrase, this would likely allow for brute-forcing it.
No, you'll still have the TPM's dictionary attack lockout.
Yes - all the times I've seen PXE boot used, the usage has been "Hold F12 during boot to reformat the disk and re-install the OS from scratch"
Which is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
Some thin clients boot from PXE so they can forego local storage completely. Being able to update the entire fleet and completely prevent any kind of local changes with a simple reboot is a gamechanger for maintainability: you can be 100% certain that every "installation" is absolutely identical.
It also wasn't uncommon to install a server's hypervisor to a USB flash drive, or a tiny local SSD. Server motherboards with internal USB-A ports (not headers, the entire port) were quite common, and there were even IDE flash drives you could plug straight into the motherboard. This allowed you to completely dedicate the regular storage to the client VMs. I would not be surprised if that same market also used PXE for the same reason in larger installations.
PXE can be great for stacks of virtual machines or thin client setups.
PXE has been enabled by default on most devices I bought, but only after USB and SSD boot failed, so in practice it's not really something you're going to see a lot of.
This is literally some security people crying wolf until everyone just stops listening to them.
They're admitting it though, at least?
I don't know where Ars Technica got that from, though. The initial advisory [1] says:
> The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance.
[1] https://github.com/tianocore/edk2/security/advisories/GHSA-9...
If such an ICMP error message comes from outside, the firewalls with stricter rules will reject it, because it does not correspond to packets sent by the victim computer.
Moreover, Ethernet booting is done usually from separate management networks to which only the administrators are connected, on which also other vulnerable protocols, like IPMI, are used, not from the main network that may have an Internet gateway.
On planet earth? Thank god the ai servers in space are safe!!
Gadzooks! I must launch my homelab into LEO, stat!! Quick <local LLM>, start me a space program!
An interesting part of this is actually in defeating secure-boot or bitlocker. If a device is misconfigured for PXE boot with an otherwise locked down UEFI system, and strong secure boot. This could let you break the boot-chain and then disable secure-boot or extract keys from a TPM.
The main question here is how often devices you'd want to try this against have PXE boot enabled. I'm thinking of locked down laptops mostly. Either corporate laptops, or manufacturer locked-down devices (chromebooks, I think some microsoft surfaces).
Servers are locked down these days too, are they not? They may have an encrypted boot image, with keys in TPM, and boot from a PXE provisioning system. Would this offer a path to modify that boot image?
How exploitable is this really? First, the machine has to do a PXE boot. In almost EVERY machine I have set up, it boots from fixed media first. Second, you have for force a machine reboot, and the machine has to be on a network you can reach.
Sure, there are lots of machines that PXE boot, but if it's on a public facing machine, why would you even configure it to PXE boot?
Arguably it's trivial to fix for most netbooting environments, the one iffy case would be corporate laptops configured to boot from net for management purposes because there "attacker controls the network and timing" suddenly can become easy
It's ICMP, so any network that doesn't filter ICMP and would allow malformed packets through could be a target. You'd have no idea when something was PXE booting, so you'd have to keep sending the packets and wait.
A bigger question I think is why you'd assign a public IP to a machine for PXE boot rather than booting it from a private IP space then assigning any publics once the OS is booted.
The astronauts on the ISS must be breathing a sigh of relief, I imagine.
They almost had a cybercriminal up there. Too bad it was all made up and the position of the first ever space criminal is back up for grabs.
How is this a 9.5 if php2shell was a 9.2?
They can't really call it a 12...
“These go to eleven”
The PHP CVS were originally reported as perfect 10s and in theory allow remote access (practically all of the internet). This requires physical hardware access (practically 0 of the internet).
Those original PHP 10s were negotiated down into a 9.2 by disclosure.. so maybe this'll be an 8.7 soon.
Well because some php configurations had an absurdly low default max upload size, which made the rce way harder. Plesk for example ships with 2m for some reason.
The fact that a subset of systems are in a less vulnerable configuration doesn't have any bearing on the CVSS score.
> Specific configurations should not impact any attribute contributing to the CVSS Base metric assessment , i.e., if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration. [1]
For a vulnerability to score a 10 its Attack Complexity must be 'Low' (broadly speaking: it doesn't require target-specific customizations or mitigations [1]), which isn't the case with php2shell.
Here's a breakdown of that 9.2: https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:H...
[1] https://www.first.org/cvss/v4.0/specification-document#Attac...
CVSS is an imperfect system. Most of the time it gets the idea of how severe an issue is across, but once you go above an 8, maybe an 8.5, there are some perverse incentives at play. Even with newer versions of the framework coming out over the years, there have always been gaps.
Even before AI, there was prestige in being able to say that you (or your team) found a 9.2 in some major piece of software. You could put that on your resume in some specializations.
Now with AI vulnerability scanning being so hyper-commercialized (but not yet fully commoditized), this is cranked way up since there are more monied interests involved, and many of them are probably trying to make a quick buck before LLM-based vulnerability scans are a commodity (for better or worse).
Check it yourself: paste CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H into a CVSS analyser and read the descriptions of the related categories.
CVSS scores are essentially meaningless. Don't read anything into it.
The beatings will continue until cybersecurity improves.
What about the other servers?
So nothing on the ISS then?
Fools! That is why I don't keep my servers on the planet Earth. Mua ha ha ha ha....
>[...] had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January
we will hopefully soon see an end to this sort of naive optimism, especially when it's an ai-assisted/ai-found vulnerability.
Can someone explain if it affects personal computers in any way?
I know my computer has UEFI. But how could a non nation state agent use that vulnerability?
Or is it just about VMs, and it's important, because the whole cloud and internet runs on VMs?
If you have network boot enabled and you’re on a recent enough uefi you’re vulnerable yes. However personal devices have uefi network boot disabled by default
I swear I have seen plenty of PCs attempt a PXE boot before failing and continuing on to the next boot option. It probably isn't the default for most "personal" machines but... That's not really a guarantee I would want to hang my hat on...
I buy ex-corporate machines for my family; they always have pxe enabled. I've got a handful of optiplex micros running my home shit. All of those.
Not only this is clickbait, they want me to solve a captcha in order to open it. What a trash website.
They had a massive amount of bot attacks recently. That captcha wasn’t always there, but the website became so slow as to be unusable. That captcha only surfaces from certain countries. It comes up far, far less frequently than it did a few weeks ago
Clearly you don't work on anything on the Web in 2026, if you're complaining about a captcha.
doesn't it also threatens most servers currently not on planet earth? like on chinas space station? i guess ISS's hardware is too old and UEFI didn't exist back then, so they are probably safe.
Aren't orbiting stations and satellites part of planet earth's space?
I was wondering about servers on satellites.
Co-ordinated disclosure may not be dead just yet, but it has started ringing around to see if anyone knows a memorial stonemason.
More buffoonery, this time from AMI.
At this moment I am not sure whether we are discovering bugs or planted backdoors.
http2shell and php2shell are both really difficult to exploit. Not that they aren't serious (and should be patched), but it's not the doomsday scenario that the news makes it out to be.
I'm wondering if this is the same.
As TFA says, this can be exploited only by someone who already has access to the internal network of the company.
Moreover, in well configured networks there is typically a separate network for the management Ethernet interfaces of the servers, to which non-authorized computers do not have access, and Ethernet booting of the servers is done through that network.
So the bug can be exploited only by a company insider, who must be an admin for the case with a separated management network, or by an external attacker who already has control over an internal computer, which must be the computer of an admin in the case with separate management network.
so how many firmwares actually compile in this ICMP stuff? because edk2 builds in a way that it will only package the stuff actually used. u include protocola and handles etc.
personally never found a reason why to include icmp in there for what i was building using edk2.
as others noted pxe is also already very fragile and enough network access to perform the icmp attack is likely enough access to mitm the entire pxe run and slap in your own boot image or modules etc.
i dont think most servers boot using PXE so that is grossly overstated? or would it include the attacker going into the boot menu and selecting to pxe boot... because why use an exploit then if you can just point it to your own server and again pull the image like that.
all u need is a konboot or similar tool inserted to then subsequently load the original image -_-
Suppose the server only boots signed images created by itself, which the PXE server happens to serve. You cannot just switch or mess with the menu. But if you can exploit the boot chain before any Secure Boot components run, then you might find your way in.
Not one single mention of coreboot in this thread? sad...
https://www.coreboot.org/
I imagine AI will expose many backdoors created by three letter agencies. This could be one.
And this is the reason why we need datacenters in space.
I'd argue datacenters in Space implies datacenters outside of Space.
Is Mars safe?
The space-based data centers will serve the exploit via the InterPlanetary File System.
Another breathless fearmongering. "threatens"? No, I don't think network booting is even all that common outside of extremely niche scenarios.
Instead, it applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources.
Who is PXE-booting over the open Internet!?
Several large bare-metal hosting companies. Not over the open Internet, but that doesn't matter if the management networks are shared and the price of admission a single server rental.
There is also HTTPS boot, which might be a lot more secure than PXE
https://tianocore-docs.github.io/EDKIIHttpsBootGettingStarte...
I would be concerned for e.g. Hetzner dedicated servers. They assumedly PXE-boot consumer grade UEFI hardware that is unlikely to have a dedicated management interface. Exploitability would depend on how well they filter ICMP within their network.
> No, I don't think network booting is even all that common outside of extremely niche scenarios.
It's incredibly common though? I've run across it and I work on games and client software, not server stuff.
> Another breathless fearmongering.
It's Ars; you come to expect it.
It's a pretty common setup on servers, even if it's not the majority. Probably more commonly it's part of the boot sequence on servers even if it's not used. I would say this is a relevant issue for most organizations' network security because of the risk it represents of being able to escalate from compromising a less privileged machine (e.g. a user's device) to a more privileged machine. It's not a 'oh god every server is going to be pwned' issue, but it doesn't need to be to be worth alerting people to.
It's always fearmongering when it comes to "vulnerabilities" that affect the model of locking down computing devices.
This shit used to confuse me so hard when I was learning security. It seemed that articles were talking about something really important, but I just couldn't connect it to anything I knew. Then I realized they weren't talking about security for users, but rather security from users - and for entities ultimately looking to restrict users (the same inversion-of-authority as TSA propaganda). Hence the syndrome of acronym hell, as that amount of overabstraction is required to motivate a system for its own purposes.
Now given that this is a network exploit, you've got to adapt my model a bit from above - my framing is most clear when talking about local "exploits" in locked down bootloaders etc. But from an individual security perspective here? If you've disabled the network stack in your BIOS (because why the hell is it there in the first place), OR put any management interfaces on their own network unreachable from anything that isn't trusted to be managing, this is an utter nothingburger.
Aah, that‘s why Musk wants space datacenters
Ok who can we sue of this bullshit? Companies forced this UEFI shit in us. So they should burn now. I am ready to grab torch and pitchforks