[AnthonyMouse]

> 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.

[Terr_]

> none of which need a mouse

Heh, I'm having flashbacks to a time repairing a computer where the BIOS/UEFI simply wouldn't work work with the regular keyboard, even though the regular OS supported it just fine.

So I had to go dig up a PS/2 one just to change settings.

[crabbone]

Absolutely this.

Not sure which article that complained about EFI mentioned that PNG parser was vulnerable... and... there's no reason for EFI to have a PNG parser really. It's a fancy stuff that could've been totally avoided. And yet, here we go...

[p_l]

And it is an optional thing you don't need to have or use, but some people like graphical logos or even animated logos so there you go...

[yencabulator]

> It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it.

I fear this would lead to vendors only implementing proprietary, Windows-only, firmware update software. UEFI-based updates and "UEFI capsules" are better than a Windows-only world, even if UEFI is not necessarily the best thing ever.

[pixl97]

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

[jasonjayr]

The flash updater IS the OS.

[AnthonyMouse]

You don't need to update the flash to boot an OS capable of updating the flash. The firmware it comes with can do that and if you've irrecoverably installed broken firmware then you've bricked your machine regardless.