UEFI Makes It Easy To Boot Rust Applications

[Luke]

If UEFI runs under the OS, that's a security issue

No, UEFI isn't an evolution of BIOS.
It is rewritten, redesigned and re-architectured from scratch.

BIOS was simple and only did basic hardware initialization and not much else.
Then it was ugly patched with hacks to make workarounds for limitations.

UEFI is much more complex and does much more than BIOS and is actually like an operating system.
It have its own network stack and can run programs and run multiple background services simultaneously.

BIOS just got the hardware running and passed control the OS.
UEFI does not pass control to the OS, because it never relinquishes control over the system to the OS, it always stays under the OS and can do its own stuff and runs it own stuff.
UEFI is kind of like an operating system and hypervisor.

When the NSA is considered a potential opponent, that's an explicit security hazard. Let me explain: Suppose the NSA plants keylogger code in a commerical BIOS, and that BIOS is in your encrypted machine. Assume the code is a keylogger. It has to be running to log your keystrokes. When you boot your encrypted DM-crypt partition, the kernel loads and takes over the keyboard prior to cryptsetup calling for the passphrase. A simple keylogger aimed at the Truecrypt bootloader will no longer be running, unless more complex and more easily found changes are made to the BIOS code.

If UEFI does not hand over control but keeps running, the danger from a firmware keylogger is greatly increased, as it would continue running at all times. We know the NSA got MS to put in back doors, we know they tried and failed to get Torvald Linus to code backdoors into the Linux kernel as they would be found. We should assume commercial UEFI to be similarly compromised until proven otherwise. I don't know how hard it will be for police and the FBI to get such a backdoor turned on, it can't export data over the network by default without being caught by someone monitoring network traffic. That's why the Guardian machine used to decrypt messages from Snowden had to be bought randomly with cash and never hooked to any network-to prevent activation of any such code.

It appears that BIOS keyloggers have not been common to date, otherwise we would not have key disclosure laws in countries that are allied with the US. The existance of attempt by courts to subpeona people for encryption keys here in the US implies the failure of technical means to defeat encryption. My worry is will this continue going forward as scandals about NSA snooping cause encryption use to spread and pressure to backdoor UEFI implementations this increases. If UEFI has the kind of power Intel V-Pro does, that's really worrysome and in my book has "Coreboot Needed!" written all over it.

[Kano]

Well the blog entry just shows how to write a very tiny UEFI app in the Rust language. Nice that this works, but it only implemented the print feature and not much more. Fine that it works but there is no real usecase i think for it. Basically you are not restricted to implement bootloaders for UEFI, if somebody wants to write Tetris for it, this should be possible as well. A UEFI shell feels like DOS somehow, just that C: is now fs0: and so on. From the source code size it is pretty huge, just take a look there:

http/tianocore.sourceforge.net

Thats an open implementation, you can use it with kvm with -L option. Should work as Coreboot payload as well:

http://www.coreboot.org/TianoCore

[uid313]

If UEFI has the kind of power Intel V-Pro does, that's really worrysome and in my book has "Coreboot Needed!" written all over it.

Yes, Intel vPro is pretty scary stuff...

[Delgarde]

Well if your rootkit can flash the UEFI firmware, yes, but I'm not sure it's possible remotely.
On the other hand, I am not sure that you are much safer from malware that could flash a BIOS.

And in theory, at least, that's the kind of thing SecureBoot is supposed to solve - by ensuring that everything that runs is signed by something in the trust chain. In practice? Who knows...

[erendorn]

But UEFI allows a EFI System partition on the disk from where it can executable EFI executables. So you don't really need to flash anything, just write a file to the disk.

You can indeed probably attack the UEFI by replacing firmware drivers, for which I'm not sure there's an equivalent for BIOS.
On the other hand, that is what secureboot is for. Because if a malware can replace files on this partition, it can change the boot loader, which is at least as compromising anyway, and probably easier, and already a vector on BIOS systems.

[Sonadow]

BIOS has a 2TB ceiling for boot volumes, so either way UEFI will be needed to accommodate larger, higher capacity storage devices.

To quote MaximumPC:

There is indeed a 2TB barrier (sorta), but it only applies to boot partitions, not all drives. And not just in Windows XP; it?s a long-standing limitation that is finally being reached by hardware.

Back in the Stone Age, floppy disks were formatted into tiny chunks?512-byte sectors, to be precise. In order to find data on a disk, the drive needs to know where to look, so each sector has an address that the Master Boot Record uses to locate information. The MBR stores disk partition information as 32-bit integers, meaning it can address a maximum of 4,292,964,296 512-byte sectors, or 2,199,023,255,552 bytes. Look familiar? It?s 2.2 tebibytes, or 2TB. Since the MBR can?t allocate addresses to partitions with more than 2TB worth of 512-byte blocks, you can?t boot from them. No problem if you?re booting from another drive, but a bummer for people who really want a massive boot partition.

The solution, as discussed in our June 2010 White Paper, is three-fold. You?ll need a motherboard that uses Extensible Firmware Interface (or EFI) instead of the 32-bit BIOS that?s standard, a GPT-initialized drive (as opposed to MBR), and a 64-bit version of Vista, Windows 7, Linux, or OS X. Only then will you be able to boot from a partition greater than 2TB. Manufacturers have resisted transitioning from BIOS/MBR to EFI/GPT, but as physical drives with more than 2TB of storage become a reality, they may finally have to comply.

[uid313]

Imagine, a boot service could call ExitBootServices only if it was successful in contacting a remote server.
This would allow some scary phone home functionality.

[erendorn]

Imagine, a boot service could call ExitBootServices only if it was successful in contacting a remote server.
This would allow some scary phone home functionality.

I don't even understand were you want to go with this one.

[uid313]

I don't even understand were you want to go with this one.

Then you cant boot without your computer phoning home.

Or if it only boot after you validated your credentials with your state-supplied security token.

Scary...

[erendorn]

Then you cant boot without your computer phoning home.

Or if it only boot after you validated your credentials with your state-supplied security token.

Scary...

Sure, what I don't get is what does it have to do with UEFI, as that's doable with any hardware.
There are hundreds of ARM devices (phones, tablets, set top boxes) that only boot signed firmware, and don't even have bios. Checking a remote connection instead of a certificate is not much more complicated.
There are also many government and enterprise hardware that indeed only boot after entering a security token.

It's not very scary either as the connection attempt would be obvious on packet sniffing, and then as a workaround you could just buy anything else.