Twitter Client for UEFI
github.com
github.com
" 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...
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
I don’t think the problem is with what people should know, but don’t.
However it is my opinion that people should learn and know more. Not everything, just more than they already do.
We should all have a decent grasp of molecule rotation and the electric dipole moment before zapping that meal in the microwave!
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.
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!
A friend of mine ported QEMU in order to run x86 boot ROMs on ARM systems.
This way, a screenreader could hook into the UI toolkit and provide a good interface.
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)
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.
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.
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.
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.
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?
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.
No. The UEFI stack lives entirely in flash, the same as BIOS did.
What is the purpose of your EFI System Partition in your opinion? That is all I was referring to in the above notes.
This is potentially not the best idea in the world...
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.
Also this might be helpful: https://pete.akeo.ie/2015/01/easily-create-uefi-applications...
and if you choose edk2: https://www.tianocore.org/
There are several pages here under the UEFI tag. There are also some application guides and a few polished bootloader documents.
Does anyone actually use it? Probably not.