Call me crazy, but security means doing only what is necessary and no more, in particular in this early part of starting up a computer system.
Call me crazy, but security means doing only what is necessary and no more, in particular in this early part of starting up a computer system.
this would be difficult without a network stack
if you're so inclined: you can remove unneeded modules from your UEFI firmware
This was possible with Ethernet cards with boot ROMs for more than two decades. Network booting via UEFI is nothing new, nothing revolutionary.
I've been installing fleets of servers with PCI ethernet cards w/ boot ROMs a decade before. Token ring systems were booting from network two decades before.
When booted from the ROM, it just downloads pxelinux.0 binary in most cases, and transfers control to it, and just vanishes.
The UEFI is persistently running at the background, has communication pipes with the OS (some of it is visible via /sys/firmware/efi), and has much larger surface like direct access to disks and network stack via drivers (it can directly read your files and work on them via proper FS driver modules).
There's also at least one open source sound driver too (https://github.com/Goldfish64/AudioPkg), so it can listen to your environment if it wants, at least in theory.
this isn't true, it ceases running once it transfers execution
you're thinking of the SMM, which is something else entirely
that's it's job
it's not the fault of the UEFI as a standard or implementation that your processor manufacturer chose to require the SMM to have its firmware loaded to boot
the UEFI also isn't suddenly persistent because there are other devices inside the machine that had firmware loaded into them (would you say the UEFI is persistent because it uploaded new third-party supplied microcode into the CPU?)
SMM being a requirement is a side effect of x86 history and platform design, not UEFI (which doesn't actually require SMM).
Thus 386SL was born, with SMM mode so that the firmware could hijack DOS without being stopped by accidental modification of interrupt table.
A bunch of stuff was later loaded into SMM for various reasons, both more and less benign. Turion X2 CPUs used SMM resident handler to synchronise cpus when going into deeper sleep levels (iirc C3 required the SMM handler, C1 and C2 were doable without, but C1E required it as well)
Looking on the bright side, that means the firmware can potentially also talk to you if you can't see the screen.
exactly the same as the UEFI
Also, now there's much less code in option rom, leading to much more coherent system. Yes, it is easier to attack, but so is any system where you can expect a standard ABI&API vs. one where you need to randomly poke things.
this is so disingenuous as to be offensive.
I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small.
Also: booting over the network is a feature of a smaller ROM on a network card, that ROM usually had a much smaller surface area and had to be explicitly called as a boot option.
Given the people who care most about network boot are people running servers: IPMI/iDRAC/iLO are much stronger options for initiating network boot.
> I'm not saying you're wrong, but the practical options for replacing a UEFI BIOS are vanishingly small.
what? you can download a GUI editor, click remove on the modules you don't want and then save it
https://www.trishtech.com/2017/12/uefitool-view-and-edit-uef...
I've done it
I also draw your attention to:
> UEFITool is only meant for the advanced users who have all the knowledge needed to modify the UEFI BIOS files. Because of you make any mistake and flash the faulty file to your motherboard, it can turn the motherboard into a dead brick.
Which is more worrying when you look at what is presented (just a bunch of UUIDs). Not exactly usable for average person who wants to minimise the attack surface of their machine.
Given that average people aren’t networking booting, wouldn’t it be wiser to have it enableable? Instead of on by default.
There's a very good reason why iPXE is so often used for chainloading and why it has support for directly replacing the option rom of the card.
I’ll bite.
How, concretely, do I do this? What’s the procedure to follow? How can I get the new BIOS image signed, so my motherboard will accept it?
they don't need to be signed
or you can dig through the manufacturers official documentation (often accessible behind NDA)
don't blame me if you brick your hardware
Take a look at ASUS motherboards, which has Armory Crate in UEFI. It will download and install software in your windows install.
...automatic bloatware from the bios.
Lovely, so you’d have to reflash the firmware to fix it.
The processors and the platform is so complex now, even with a secure UEFI, there are many points into the system both with add-on cards and your Ethernet port and bowels of the platform which has many controllers with Ring -1 (and deeper) access, where Ring 0 is the OS kernel level access.
You can already do all sorts of tricks with net booting, any HTTP stack needs can be deferred to run in the OS.
I worked extensively with UEFI in a past job and every implementation I could find had large bugs of some kind. It is fine at booting the system but managing it is a nightmare, and it seems like UEFI prompt is designed to be as obtuse as possible. And I didn't even know it could do HTTP calls!