Twitter Client for UEFI(github.com)
github.com
Twitter Client for UEFI
https://github.com/arata-nvm/mitnal
21 comments
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/
Yeah, I always assumed it meant "post" as in "after", and it meant "after starting up" or something
For anyone wanting to know how UEFI actually works, I always recommend this article: https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...
shrimp_emoji(2)
This should be common knowledge among everyone using a computer. It just makes sense to know how your device operates, and it's not hard to learn.
Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D
Having been the go to guy for fixing anything remotely computer related, I got sick of it and I just wish everyone could fix their own stuff :D
Why stop at using a computer, you could apply this sentiment to every item anyone may use.
We should all have a decent grasp of molecule rotation and the electric dipole moment before zapping that meal in the microwave!
We should all have a decent grasp of molecule rotation and the electric dipole moment before zapping that meal in the microwave!
I'd probably wreck meals less if I understood how microwaves act on foods with varying moisture and lipid proportions.
I said "should" and I meant it.
You don't have to, no one has to.
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.
You don't have to, no one has to.
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.
You seem to have a frustration with people around you.
I don’t think the problem is with what people should know, but don’t.
I don’t think the problem is with what people should know, but don’t.
I don't anymore, because I understood I can't affect other people, so I must not care.
However it is my opinion that people should learn and know more. Not everything, just more than they already do.
However it is my opinion that people should learn and know more. Not everything, just more than they already do.
I get the feeling UEFI can never be entirely secure with the set of functionality it offers and thus huge surface it is exposing.
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.
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.
customers want to be able to boot their machines off the network
this would be difficult without a network stack
if you're so inclined: you can remove unneeded modules from your UEFI firmware
this would be difficult without a network stack
if you're so inclined: you can remove unneeded modules from your UEFI firmware
> this would be difficult without a network stack
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.
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.
what's the difference between having the code running in ring0 in a ROM vs the code running in ring0 from UEFI?
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.
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.
> The UEFI is persistently running at the background, has communication pipes with the OS
this isn't true, it ceases running once it transfers execution
you're thinking of the SMM, which is something else entirely
this isn't true, it ceases running once it transfers execution
you're thinking of the SMM, which is something else entirely
SMM is also part of the firmware, it is set up by UEFI.
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?)
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 provides an interface to register code that runs in SMM, true.
SMM being a requirement is a side effect of x86 history and platform design, not UEFI (which doesn't actually require SMM).
SMM being a requirement is a side effect of x86 history and platform design, not UEFI (which doesn't actually require SMM).
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 :(
I don't think SMM requires UEFI, either, actually... I believe there have been BIOSes that initialized SMM also.
[deleted]
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)
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 also at least one open source sound driver too
Looking on the bright side, that means the firmware can potentially also talk to you if you can't see the screen.
Looking on the bright side, that means the firmware can potentially also talk to you if you can't see the screen.
There's a huge difference. The network card does not need unrestricted access to the entire system.
it has it because the code running from its ROM is running in ring0
exactly the same as the UEFI
exactly the same as the UEFI
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.
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.
You do know how DMA works right?
> 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.
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.
> 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.
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'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
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.
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).
Does it not need a digital signature or something?
The ROMs on NICs had huge attack surfaces, as each rom had to implement enough network stack from scratch. Not to mention how buggy they were.
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.
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.
It’s so easy to do. Literally unchecking boxes on a gui.
> if you're so inclined: you can remove unneeded modules from your UEFI firmware
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?
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?
there are plenty of forums dedicated to this, here is a guide to do exactly what I described above: https://www.win-raid.com/t3061f16-Guide-How-to-extract-inser...
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
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
You can boot to a stub OS on the system that can chainload whatever you want afterwards. This is how GRUB et al work.
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.
Many uefi systems do lots of "fun things" because they have network access.
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.
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.
Lenovo’s superfish was my favorite example of that
As demonstrated by MoonBounce: https://securelist.com/moonbounce-the-dark-side-of-uefi-firm...
> 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.
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.
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!
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!
This made me wonder if somebody got Doom to run under UEFI, and sure enough:
https://github.com/Cacodemon345/uefidoom/
https://github.com/Cacodemon345/uefidoom/
UEFI is like the ugly son of MS-DOS and Windows. Anything that can run under MS-DOS with a DOS extender can run under UEFI.
A friend of mine ported QEMU in order to run x86 boot ROMs on ARM systems.
A friend of mine ported QEMU in order to run x86 boot ROMs on ARM systems.
That's... so absurd but so genius.
was about to comment this. Now I have to find ridiculous things to run on uefi.
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.
See this project: https://github.com/Goldfish64/AudioPkg
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.
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.
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.
TIL: It's possible for UEFI code to access the internet. What could possibly go wrong?
How did you think netbooting support works?
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)
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)
I thought that was the Intel ME thing. I've actually never used netboot.
> 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.
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.
How about this heap overflow bug in the UEFI bitmap (BMP) library: https://nvd.nist.gov/vuln/detail/CVE-2021-38577
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.
For comparison, Heartbleed scored a 7.5: https://nvd.nist.gov/vuln/detail/CVE-2014-0160
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.
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.
For comparison, Heartbleed scored a 7.5: https://nvd.nist.gov/vuln/detail/CVE-2014-0160
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.
PXE boot has been supported since before UEFI was a thing.
Wasn't it always possible? If it can boot a full-blown OS that can access the internet, it has to be able to access the internet on its own.
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.
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.
[deleted]
this is the bloat free software that i need in my life
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.
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.
> and finally your very safe and secure OS running.
That's the one running on the Intel Management Engine, right? Or at least Intel would like to believe that's the case.
Jokes aside, I may be missing something. The BIOS came way before UEFI did. What am I missing here?
That's the one running on the Intel Management Engine, right? Or at least Intel would like to believe that's the case.
Jokes aside, I may be missing something. The BIOS came way before UEFI did. What am I missing here?
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
new way is UEFI --> Boot loader --> Kernel --> OS
Reality is for new way:
Non-BIOS BIOS --> UEFI --> 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.
So what is being sold is:
old way is BIOS --> MBR --> Boot loader --> Kernel --> OS
new way is UEFI --> Boot loader --> Kernel --> OS
Reality is for new way:
Non-BIOS BIOS --> UEFI --> 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.
> Something has to start reach and load the UEFI written on a 'boot media'
No. The UEFI stack lives entirely in flash, the same as BIOS did.
No. The UEFI stack lives entirely in flash, the same as BIOS did.
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.
Can you point at a machine like this? Literally every machine I've worked with has UEFI entirely implemented in motherboard flash.
I think we are talking (writing) past each other.
What is the purpose of your EFI System Partition in your opinion? That is all I was referring to in the above notes.
What is the purpose of your EFI System Partition in your opinion? That is all I was referring to in the above notes.
It contains bootloaders.
What would be the purpose of this? A no-GUI client that’s loaded before the OS?
File this project under: the engineers were so preoccupied with whether or not they could, they didn’t stop to think about if they should.
Would it be possible to run light weight apps/containers based on Wasm/Wasi? What are the limitations of UEFI?
> You need to enable "HTTP Protocol Stack Support" in your UEFI.
This is potentially not the best idea in the world...
This is potentially not the best idea in the world...
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
This was part of their "eBetween" UEFI BIOS that enabled them to show ads during boot-up (seriously) and also install software to Windows with what they called "Virtual Bundling Technology": https://indexarticles.com/business/business-wire/phoenix-tec... and https://www.cnet.com/tech/tech-industry/phoenix-jumps-on-web...
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.
This was part of their "eBetween" UEFI BIOS that enabled them to show ads during boot-up (seriously) and also install software to Windows with what they called "Virtual Bundling Technology": https://indexarticles.com/business/business-wire/phoenix-tec... and https://www.cnet.com/tech/tech-industry/phoenix-jumps-on-web...
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.
Anyone have a favorite guide/blog post/whatever for getting started with UEFI applications?
Not a tutorial but good info and keywords https://www.intel.com/content/dam/develop/external/us/en/doc...
Also this might be helpful: https://pete.akeo.ie/2015/01/easily-create-uefi-applications...
and if you choose edk2: https://www.tianocore.org/
Also this might be helpful: https://pete.akeo.ie/2015/01/easily-create-uefi-applications...
and if you choose edk2: https://www.tianocore.org/
https://wiki.osdev.org/UEFI
There are several pages here under the UEFI tag. There are also some application guides and a few polished bootloader documents.
There are several pages here under the UEFI tag. There are also some application guides and a few polished bootloader documents.
Doom for UEFI, twitter for UEFI, what's next? A video player for UEFI?
This sounds like a perfect command and control setup for malware.
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).
Exactly. My first thought was bootkit as standalone C2 would not be that useful
I'm impressed when they have VirtualBox or qemu running in UEFI, sandboxing my real OS.
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.
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
" 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...