4 ms·

Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the

Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces. In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.

tliltocatl 1y ago
That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).
hypercube33 1y ago
EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.
- hulitu 1y ago
  > EFI was part of the itanium culture at Intel That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?
msgodel 1y ago
You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.
m4rtink 1y ago
Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices. As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
jeroenhd 1y ago
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement. I'll take UEFI over BIOS any time if only because it finally solved dual booting.
- xg15 1y ago
  > modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS? This stuff seems inches away from a supply chain attack.
  - OptionOfT 1y ago
    https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F8%2Fa%2F2%2F8a2fb72d-9b96-4e2d-a559-4a27cf905a80%2Fwindows-platform-binary-table.docx&wdOrigin=BROWSELINK https://view.officeapps.live.com/op/view.aspx?src=https%3A%2... It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
- hulitu 1y ago
  > I'll take UEFI over BIOS any time if only because it finally solved dual booting. With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.
DSMan195276 1y ago
The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.
- RiverCrochet 1y ago
  All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI. The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer. A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
  - Avamander 1y ago
    > Linux lets you build a devicetree as part of the kernel. And it's absolutely awful as an end user if you have anything even slightly unusual.

tliltocatl 1y ago

That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).

hypercube33 1y ago

EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.

hulitu 1y ago
> EFI was part of the itanium culture at Intel That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?

msgodel 1y ago

You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.

m4rtink 1y ago

Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices. As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.

jeroenhd 1y ago

UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement. I'll take UEFI over BIOS any time if only because it finally solved dual booting.

xg15 1y ago
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS? This stuff seems inches away from a supply chain attack.
- OptionOfT 1y ago
  https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F8%2Fa%2F2%2F8a2fb72d-9b96-4e2d-a559-4a27cf905a80%2Fwindows-platform-binary-table.docx&wdOrigin=BROWSELINK https://view.officeapps.live.com/op/view.aspx?src=https%3A%2... It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
hulitu 1y ago
> I'll take UEFI over BIOS any time if only because it finally solved dual booting. With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.

DSMan195276 1y ago

The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.

RiverCrochet 1y ago
All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI. The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer. A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
- Avamander 1y ago
  > Linux lets you build a devicetree as part of the kernel. And it's absolutely awful as an end user if you have anything even slightly unusual.