" UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors.
The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hardware components, ensures they’re functioning properly, and then runs the bootloader that boots Windows or whatever other operating system you have installed.
You can configure various settings in the BIOS setup screen. Settings like your computer’s hardware configuration, system time, and boot order are located here.
The BIOS goes through a POST, or Power-On Self Test, before booting your operating system. It checks to ensure your hardware configuration is valid and working properly."
Thanks for this. I had a generally good idea about this, but despite seeing the word for many years, never actually knew what POST stood for before this comment. I'm not even sure I knew that it was an acronym...
If you're interested in learning further, I wrote up everything in the "regular" (pre-UEFI) boot process here and have been told it's a very good crash course on how your PC boots up: https://neosmart.net/wiki/mbr-boot-process/
It's because 95% of people do not care or don't like playing around with their computers or accessing the UEFI menu for sys-admin, netbooting, recovery, ransomware development or building their PCs.
Apple does the same thing without the spooky UEFI menus on PCs, called 'Internet Recovery' which is still using EFI and is just like how netbooting works; and that 'just works'.
The filevault unlock screen interestingly enough is an EFI application, carefully constructed to look like the normal login screen. It's probably the most used EFI app that normal users interact with.
People can use locked down hardware and be at the mercy of the manufacturers and support services.
There's a lot more money in that than everyone fixing their own shit.
Same way people who know nothing about how democracy and their country works can still vote. For some reason, they often want more authoritarianism, go figure.
And those replies of "why not know everything hehe" always lead to dismissing the whole argument.
UEFI needs ~complete access to the machine so it can initialize hardware devices and pass control to the OS (which also has ~complete control of the hardware). How do you think sandboxing it would work, practically?
What’s scary about UEFI is that it has both direct hardware access and a massive attack surface: GUI, Ethernet stack, occasionally an 802.11 stack, etc.
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 a boot ROM fires (it was via INT19 IIRC), the boot ROM runs, terminates and leaves the system. The size is smaller, it's not persistent, and it can't communicate with anything on the OS.
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.
yes, the UEFI initialises the machine such that it is in a state that it can boot
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?)
UEFI Secure Boot requires SMM (because it secures access to the key vault). Non-x86 architectures use something else, for example they could use EL3 on ARM. Either way it's a "super-supervisor mode" of sorts.
Well, it does not have to be SMM that does it - it's just that SMM is what we have already available so unless you have certain rare hw it's what vendors will use :(
Indeed. SMM exists because it was unfeasible to require the OS to provide necessary power management features at a time when running DOS and unmodified Win2.x and Win3.x were crucial features.
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)
UEFI is not persistent by itself - anything that is persistent was also persistent on BIOS-based systems. The only remaining elements of UEFI that are accessible after ExitBootServices() call (done by OS during boot) is interface to edit NVRAM variables and a way to register so-called "capsules" (used, for example, for firmware updates.)
There's less unrestricted access with UEFI than with old-fashioned option rom, especially with how you can 1) prevent loading of an option rom by banning its signature 2) register override for the device.
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.
> if you're so inclined: you can remove unneeded modules from your UEFI firmware
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.
Cool tool, didn’t know it existed but there are so many variations on UEFI bios’s that I can’t help but feel it will not universally work, and it depends a lot on things being compartmentalised.
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.
On my consumer grade motherboards netboot and the UEFI network stack is off by default. Network access code is still there though for purposes like online update (manually done).
Yeah, every time I have to update my bios over ethernet, I kind of just shudder internally. Downloading and flashing is a pain, but it still just feels wrong for some reason.
> Due to its emplacement on SPI flash which is located on the motherboard instead of the hard disk, the implant is capable of persisting in the system across disk formatting or replacement
Lovely, so you’d have to reflash the firmware to fix it.
We've past this point with Intel ME, AMD's counterpart, and UEFI being an embedded OS which can run arbitrary binaries with free pass to everything on the system, almost ~10 years ago.
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.
Yeah I really don't understand why this crap needs to be so capable.
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!
Has anyone implemented audio output on a modern x64 machine under UEFI, e.g. using the typical Realtek on-board audio? If so, I'd like to get a GUI with a screen reader working under UEFI sometime, both for the challenge of getting into bare-metal programming, and because as far as I know, nobody has made a PC boot process and firmware setup UI (what we used to call BIOS setup) accessible to blind people.
It would be very interesting project, because UEFI also puts emphasis on unified UI stack - yes, you can do stupid bling setup interface still, but there's somewhat unified UI toolkit available + standardised ways to create configuration options for devices.
This way, a screenreader could hook into the UI toolkit and provide a good interface.
Now imagine a whole working set of software, and some encrypted storage, running in UEFI, while the "real OS" with some games and office apps is only loaded to plausibly deny the real use.
A few thoughts: yes, UEFI is a large attack surface. Secure Boot mitigates a lot of that - if it's turned on, the vast majority of UEFI functionality is only accessible to signed binaries. If you're running untrustworthy code in your boot environment then it's already in a position to just overwrite the firmware, there's no memory protection here. But UEFI doesn't entirely go away after the OS boots, there's some number of runtime services left that the OS depends on. http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html is a demonstration that if you're able to modify those then you can compromise the OS. There's also, of course, all the code in SMM which can just do whatever and may have been audited but possibly hasn't been.
But honestly overall BIOS was a bigger concern than UEFI. It's easy to forget, but a lot of the BIOS hooks are still available at runtime - https://github.com/mqudsi/lrmi is an interface that lets you call them from Linux. It's reasonable to worry about the attack surface exposed by UEFI runtime services, but BIOS software interrupts are frankly even weirder. The reason we largely didn't worry about them is that you normally have to be root to call them, which is also the case for UEFI runtime services and most SMM interfaces. And SMM definitely predates UEFI, so getting away from UEFI complexity wouldn't save us there.
And there's been plenty of meaningful security work done in the UEFI space lately. There's support for proper IOMMU setup so that you can boot off Thunderbolt without any Thunderbolt device just being able to DMA all over your firmware. The NX bit is supported. There's support for stack canaries. There are best practices for SMM behaviour. https://uefi.org/sites/default/files/resources/UEFI%20Firmwa... covers a bunch of this.
If we were designing firmware for maximum security then I don't think anyone would argue we'd come up with UEFI. That doesn't mean that we should be nostalgic about BIOS, which was a smaller attack surface but provided no meaningful security.
UEFI made it quite simpler by making it so that network cards only have to bring a driver in OPROM instead of whole stack as before, and this allowed important improvements into boot process (like HTTPS instead of TFTP)
> TIL: It's possible for UEFI code to access the internet.
Quite surprising to see lots of tech-oriented users here finally discovering UEFI having access to the internet after years of even the basics like "Internet Recovery" being used on Apple Macs or even sysadmins using netbooting on diskless systems.
There is always a IP/Net stack section in the UEFI menu on nearly every modern PC which gives you this hint, but it isn't useful for the 95% of users, except for sysadmins, recovery, security and even malware writers.
> What could possibly go wrong?
Indeed. A lot can go wrong. I bet someone will do a Wordle clone in UEFI next.
Exploitable via network, no user interaction and no special privileges required. Scores 9.8 on a scale of 10 for severity from NIST. That's what happens when this stuff is done in such a highly privileged environment - simple bugs become security nightmares.
Secure boot and signed firmware won't save you, and in fact it could make things worse since it means even well-informed and capable users won't be able to fix it on their own. They're utterly helpless until their vendor fixes it and publishes an update.
I think your logic is faulty here. There were BIOSes with no ip stack for many years that could boot OSes that did have the ability to access the internet.
Also, it's possible to remove the ip stack from most UEFI implementations?
Now, it does need a network stack if it's going to _boot_ the other OS from the network.
If this allows me to use “latest tweets” chronological view as default instead of the brain dead “home” view I’m totally setting up a laptop with this. The official twitter clients are more atrocious each day (spaces? Home by default? 95% promoted tweets in my timeline? List suggestions I don’t care about?)
/s
Gather around children. Let me tell you a story from long long time ago.
Two one eyed giants, Intel and Microsoft got together and decided that they should be in control of your machine, not the other half giants, like AMI, Award,Phoenix, DTK, and even a full giant but nobody cared about her, IBM.
So they convinced everyone there was no space on the BIOS any more, and they had to shift much of the code outside onto a boot device, usually an HDD. 'Think about all the speed and ability to update quickly' they said to the peasants, and the local magistrates in the form of media gobbled it up, and continue to spread this news. There were some peasants that freaked out, pointed out the problem, but quickly were shouted down and jeered at by the crowd. 'We want faster! Stop spreading misinformation.'
And, the two giant indeed forced the development of EFI then UEFI. There is nothing Unified about it. But, guess what? That was not good enough either, because some peasants figured it out how to manipulate the UEFI, and the two giant didn't like that. So they went back to the half giants and discussed what to do.
And, lo they came up with an brand new idea! What if we put all this information into a chip, and make it hard to read! We will call it, BIOS! For good measure, for peasants that want more power, we will even throw in another one, and we will call it Baseboard Management Controller, but we will let you call that all kinds of different names! To make it even more entertaining, in larger cities where peasants are promoted to the rank of "enterprise", some host board adapters will also run OSes themselves for the fun of it.
And this is how we got to today. When your computer runs, the BIOS with a full OS can be running, next to it, the BMC with a full OS could be running, on top of the BIOS you can have UEFI running, the HBA OSes running, and finally your very safe and secure OS running.
/story
I have taken artistic liberty (like UEFI most often runs on the same CPU,while BMC & HBA run on their own, and such), but the gist is true.
An enterprise class host can be running many fully functional OSes, potentially with full network stack. This is why "zero trust" network implementation is so important.
UEFI did not replace the BIOS. You must have an onboard storage (usually a EEPROM)that loads all the UEFI. To load the UEFI, it still needs to know about devices and such, so that onboard thing albeit we no longer allowed to call BIOS, is... the BIOS. It is the 0 stage loader, or pre-loader, or pre-UEFI boot loader; just do not call it BIOS because it hurt feelings.
So what is being sold is:
old way is BIOS --> MBR --> Boot loader --> Kernel --> OS
Something has to start reach and load the UEFI written on a 'boot media' (and we cannot forget about backward compatibility and fallback). Call it whatever you want, but it provides basic input, and output system to reach the media which stores the UEFI code.
Put it in an other way, UEFI is (supposed to be) nothing more than just a set of easily updatable libraries of drivers and tooling to update the drivers; all in the background for your convenience. The old fashioned BIOS was not expanded to be storing all the various new fangled stuff we attach to machines, and the drivers update 'so fast' you would be flashing them almost every month.
In my experience, it may be on a detachable flash media, but it is not entirely in flash on the motherboard. That would be counter to 'expandability' concept of UEFI. I have never seen so much flash memory directly on the mobo to support UEFI.
Ya'll ain't seen nothing yet. For a time the leading UEFI vendor, Phoenix Technologies, had a web browser in their UEFI BIOS. Some photos from WinHEC 2005 can be seen here: https://www.anandtech.com/show/1670/8
tl;dr version: UEFI can download software from the internet, copy it to the Windows partition, edit the registry, and even add desktop icons and IE bookmarks. Phoenix sought to productize this.
If you've ever seen a Windows PC where you just couldn't get rid of certain pieces of software or icons, it may have been eBetween at work. This is effectively the same thing as the persistent malware attacks described in numerous security blogs. Phoenix has since rebranded their UEFI codebase to (irony alert!) SecureCore.
It's not really a good option, however SMM mode could be (you'd need to figure how to do network calls, though). The only thing changed by UEFI in this case is unified interface to register SMM components (You can have UEFI system with no SMM).
Why would you want qemu running in UEFI, rather than have qemu booted from UEFI? (more specifically run qemu on xen booted from UEFI, I think is what you'd want).
Practically speaking, QEMU needs a lot of OS functionality, such as scheduling, threading, virtual memory, and network, disk, and filesystem drivers, to be able to function. Xen does have these, but so does Linux, and KVM just exposes hardware virtualization as a module from Linux.
" UEFI and BIOS are low-level software that starts when you boot your PC before booting your operating system, but UEFI is a more modern solution, supporting larger hard drives, faster boot times, more security features, and—conveniently—graphics and mouse cursors.
The UEFI/BIOS loads when your computer starts up, and the BIOS is responsible for waking up your computer’s hardware components, ensures they’re functioning properly, and then runs the bootloader that boots Windows or whatever other operating system you have installed.
You can configure various settings in the BIOS setup screen. Settings like your computer’s hardware configuration, system time, and boot order are located here.
The BIOS goes through a POST, or Power-On Self Test, before booting your operating system. It checks to ensure your hardware configuration is valid and working properly."
Source: https://www.howtogeek.com/56958/htg-explains-how-uefi-will-r...