Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Damn Vulnerable UEFI

github.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Damn Vulnerable UEFI

#11

Post by Rinzler89 »

LtdJorge wrote: post #9
Rinzler89 wrote: post #6

Earlier quoted context omitted.

>I'm curious about that - why isn't there more competition Because like most consumer PC parts, it's a race to the bottom low margin low wage business, usually offshored to Asia, that's only remotely profitable for the top 2-3 players who captured the market and optimized the costs, processes, development and supply chain to the max. Why would anyone else want to enter such a market to compete for even lower profits?

Most, if not all, consumer motherboard manufacturers are Asian themselves (Taiwan)

Sure, but must major BIOS manufacturers, Award, Phoenix, AMI are American AFAIK.

Re: Damn Vulnerable UEFI

#12

Post by blueflow »

paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

My favourite pet peeves that i love to complain about (repeatedly):

- The GPT partition scheme inherited mixed-endianness UUID from Windows 3.1. Some people argue it does not qualify as mixed-endianness, but it is the struct from Windows 3.1 and its not evident from a printed UUID whether it is the Windows format or Big Endian as the standard says.

- Default file system for EFI is FAT, which was originally made for floppies and 8.3 filenames. Everything above 32MB and 11-byte filenames is hacked on top. There were a ton of competing, incompatible implementations until the Microsoft Extensible Firmware Initiative standardized it. FAT should deserve a long list on its own.

- EFI binaries are Windows PE executables, and PE executables are starting with the MS-DOS MZ header as introduced with MS-DOS 3 (or was it 2?). The "This program cannot be run in DOS mode" header.

From an osdev perspective, EFI is hideous. Good luck implementing that stuff for your own OS.

For secureboot: On one side i hope that Microsoft gets hacked and their EFI signing key leaked, on the other side i'm confident this has already happened.

Re: Damn Vulnerable UEFI

#13

Post by blueflow »

harshreality wrote: post #10
paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works.

Its just the x86 platform that is shite.

Re: Damn Vulnerable UEFI

#14

Post by AnthonyMouse »

harshreality wrote: post #10
paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile?

It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper on the system board if you like.

> How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot?

You give the OS access to the flash and then document what the bits do so the OS knows what to change.

> Granted, most of what goes on in a BIOS is displaying and changing variables involved in getting the system running, and maintaining those values, which just requires some sort of minimal editing interface and nv storage, but then... users appear. They want to be able to use a mouse. They want an ability to configure their raid chipset prior to boot, or netboot, and HW makers want to implement that in a way that's not some arcane raw assembly dance between BIOS and additional chip FW. What then?

Limit the firmware UI to extremely basic settings like "restore factory defaults" and "choose boot device", none of which need a mouse. Boot an OS to do anything more complicated.

> UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.

The reason these are all terrible is that they're supplied by the OEM. Delete all of them and replace them with hardware documentation that allows anyone to write their own. Ship the machine with an open source reference implementation that most people will never have to change unless it's terrible, in which case the 0.1% of the users that care will fix it and you can incorporate the fix into the reference implementation.

Re: Damn Vulnerable UEFI

#15

Post by Antip0dean »

paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

> ...we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction...

My initial suspicion was that this was about preparing the ground for closed computing regardless of the surrounding hardware.

That this hasn't happened suggests it's just my imagination gone wild, it's a missed opportunity for (say) Microsoft, or the folks behind it had good intentions. Occam's Razor, I guess?

Re: Damn Vulnerable UEFI

#16

Post by kokada »

blueflow wrote: post #13
harshreality wrote: post #10

Earlier quoted context omitted.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works. Its just the x86 platform that is shite.

However each OpenWRT router also has its own custom bootloader AFAIK. This is why you need different images for different devices, and can't create a single image for everything. UEFI on the other hand you just build one image and it works everywhere.

Re: Damn Vulnerable UEFI

#17

Post by i80and »

paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

It sounds like what you want is Coreboot?

Which it seems like AMD is interested in from the slides in [1]

[1]: https://community.amd.com/t5/business/empowering-the-industr...

Re: Damn Vulnerable UEFI

#18

Post by pixl97 »

AnthonyMouse wrote: post #14
harshreality wrote: post #10

Earlier quoted context omitted.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

And when you don't have an OS because you need to update the flash first?

Re: Damn Vulnerable UEFI

#19

Post by blueflow »

kokada wrote: post #16
blueflow wrote: post #13

Earlier quoted context omitted.

No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works. Its just the x86 platform that is shite.

However each OpenWRT router also has its own custom bootloader AFAIK. This is why you need different images for different devices, and can't create a single image for everything. UEFI on the other hand you just build one image and it works everywhere.

> UEFI on the other hand you just build one image and it works everywhere.

Thats the theory. Practice looks like that: https://lore.kernel.org/linux-efi/20200907170021.GA2284449@r...

If Vendors couldn't get the BIOS consistently right in the 80ies, why would they get UEFI consistently right now?

Re: Damn Vulnerable UEFI

#20

Post by pjmlp »

paol wrote: post #7

I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.

Fear not, Microsoft has an ongoing Rust implementation, and then everything will be sorted out. /s

https://techcommunity.microsoft.com/t5/surface-it-pro-blog/r...

Post reply on HN