3 ms·

UEFI was shoved down our throat, but today I can't think of one example where UEFI is better than BIOS, other than the partition size limit.

by 1970-01-01 3y ago

zamadatix 3y ago
The changes in UEFI are mostly for hardware manufacturers. There's only so much user facing functionality in boot firmware. One other thing it did better enable, through better support of modern hardware and the standardized extensibility, is GUI firmware interfaces. If you get into fancier enterprise hardware use cases the modules are also nice.
csdvrx 3y ago
You can use a BIOS with GPT (which remove partition size limit using LBA48) : see EDD 4 page on 4 https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_annex.pdf https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_a... : "Hybrid MBR boot code overview: This annex describes how MBR boot code called hybrid MBR boot code may be constructed to support a GPT disk layout (see UEFI-2.3) in a legacy BIOS system." I'm working on that for one of my projects. A BIOS can use GPT partitions to have LBA48, but MBR partitions standards could laso be changed to use LBA48 instead of LBA32 which cause the limit You could even use the CHS fields to have even more space if needed: there are 3 bytes for the CHS start, 3 others for the CHS end, both are often wasted by storing 0 for LBA32. That said, I still consider UEFI to be better for at least 1) multiplatform support (have different /EFI/BOOT paths to payloads named by their architecture) 2) fallbacks (shell + startup.nsh) 3) defining how the persistence of settings work (efivars)
Thoreandan 3y ago
For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike: * Not having a minimal straightforward shell to troubleshoot from * Not letting the UEFI variables be easily user accessible/fixable
- yencabulator 3y ago
  > * Not having a minimal straightforward shell to troubleshoot from There is a shell for UEFI. It feels a lot like a reimplementation of MS-DOS shell, with "FS0:" to change drives etc, but it has directory listings, file copying, etc. The interface is standardized and there's an open source implementation in EDK2. If you build Linux kernels as "EFISTUB", they're simply executables in the UEFI shell. https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg https://github.com/tianocore/tianocore.github.io/wiki/ShellP...
- tremon 3y ago
  > Not having "extended partitions" as a concept to deal with You can BIOS boot from a GPT-partitioned disk just fine. > OS booting not dependant on "load an MSDOS bootblock from LBA offset X" The only offset that's hardcoded by the BIOS is LBA block 0. The rest is from your bootloader. And GPT partitioning allows you to put the bootloader code in a proper partition rather than in the void under the stairs: https://en.wikipedia.org/wiki/BIOS_boot_partition https://en.wikipedia.org/wiki/BIOS_boot_partition > Not having a minimal straightforward shell to troubleshoot from Download shellx64.efi from the (Intel) EFI development kit. When it's present in the root directory of your EFI System Partition, most firmwares will include an option to boot into that shell. Or is your objection that it's an DOS-inspired command prompt rather than a Unix shell? > Not letting the UEFI variables be easily user accessible/fixable Don't know about this one. The linux kernel supports reading and writing EFI variables through efivarfs, but I don't know if that is predicated on firmware support and whether it includes access to all variables.
drewg123 3y ago
UEFI allows you to programmatically change the boot device from inside the OS. This is important for failed or degraded SSDs, as they can fail in weird ways (read only, all reads hang, etc) such that trying to boot from them can hang the system. That allows you to detect a failing boot driver, and gracefully fall back to booting from another mirror/raid member and avoid having to have somebody touch a server by hand. There are plenty of other firmware systems that allow for the same thing, and I dislike UEFI as much as the next guy, but this is a feature that's been important at work.
- akira2501 3y ago
  efivars is probably the goofiest and most uncomfortable way of handling this. They created this giant wasteful infrastructure in EFI and at the end of the day, you're still poking around in a bespoke filesystem to hopefully communicate GUID tagged facts about your boot drives to your bios. There were tons of other ways this could have been accomplished for far less effort and with previously existing systems.
AzzyHN 3y ago
Secure boot more or less prevents rootkits entirely
- autoexec 3y ago
  Except when it doesn't https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/ https://arstechnica.com/information-technology/2023/03/unkil... thanks to UEFI. There have been previous issues as well https://www.bleepingcomputer.com/news/security/microsoft-fixes-secure-boot-bug-allowing-windows-rootkit-installation/ https://www.bleepingcomputer.com/news/security/microsoft-fix...

UEFI was shoved down our throat, but today I can't think of one example where UEFI is better than BIOS, other than the partition size limit.

zamadatix 3y ago

The changes in UEFI are mostly for hardware manufacturers. There's only so much user facing functionality in boot firmware. One other thing it did better enable, through better support of modern hardware and the standardized extensibility, is GUI firmware interfaces. If you get into fancier enterprise hardware use cases the modules are also nice.

csdvrx 3y ago

You can use a BIOS with GPT (which remove partition size limit using LBA48) : see EDD 4 page on 4 https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_annex.pdf https://www.fpmurphy.com/public/EDD-4_Hybrid_MBR_boot_code_a... : "Hybrid MBR boot code overview: This annex describes how MBR boot code called hybrid MBR boot code may be constructed to support a GPT disk layout (see UEFI-2.3) in a legacy BIOS system." I'm working on that for one of my projects. A BIOS can use GPT partitions to have LBA48, but MBR partitions standards could laso be changed to use LBA48 instead of LBA32 which cause the limit You could even use the CHS fields to have even more space if needed: there are 3 bytes for the CHS start, 3 others for the CHS end, both are often wasted by storing 0 for LBA32. That said, I still consider UEFI to be better for at least 1) multiplatform support (have different /EFI/BOOT paths to payloads named by their architecture) 2) fallbacks (shell + startup.nsh) 3) defining how the persistence of settings work (efivars)

Thoreandan 3y ago

For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike: * Not having a minimal straightforward shell to troubleshoot from * Not letting the UEFI variables be easily user accessible/fixable

yencabulator 3y ago
> * Not having a minimal straightforward shell to troubleshoot from There is a shell for UEFI. It feels a lot like a reimplementation of MS-DOS shell, with "FS0:" to change drives etc, but it has directory listings, file copying, etc. The interface is standardized and there's an open source implementation in EDK2. If you build Linux kernels as "EFISTUB", they're simply executables in the UEFI shell. https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg https://github.com/tianocore/tianocore.github.io/wiki/ShellP...
tremon 3y ago
> Not having "extended partitions" as a concept to deal with You can BIOS boot from a GPT-partitioned disk just fine. > OS booting not dependant on "load an MSDOS bootblock from LBA offset X" The only offset that's hardcoded by the BIOS is LBA block 0. The rest is from your bootloader. And GPT partitioning allows you to put the bootloader code in a proper partition rather than in the void under the stairs: https://en.wikipedia.org/wiki/BIOS_boot_partition https://en.wikipedia.org/wiki/BIOS_boot_partition > Not having a minimal straightforward shell to troubleshoot from Download shellx64.efi from the (Intel) EFI development kit. When it's present in the root directory of your EFI System Partition, most firmwares will include an option to boot into that shell. Or is your objection that it's an DOS-inspired command prompt rather than a Unix shell? > Not letting the UEFI variables be easily user accessible/fixable Don't know about this one. The linux kernel supports reading and writing EFI variables through efivarfs, but I don't know if that is predicated on firmware support and whether it includes access to all variables.

drewg123 3y ago

UEFI allows you to programmatically change the boot device from inside the OS. This is important for failed or degraded SSDs, as they can fail in weird ways (read only, all reads hang, etc) such that trying to boot from them can hang the system. That allows you to detect a failing boot driver, and gracefully fall back to booting from another mirror/raid member and avoid having to have somebody touch a server by hand. There are plenty of other firmware systems that allow for the same thing, and I dislike UEFI as much as the next guy, but this is a feature that's been important at work.

akira2501 3y ago
efivars is probably the goofiest and most uncomfortable way of handling this. They created this giant wasteful infrastructure in EFI and at the end of the day, you're still poking around in a bespoke filesystem to hopefully communicate GUID tagged facts about your boot drives to your bios. There were tons of other ways this could have been accomplished for far less effort and with previously existing systems.

AzzyHN 3y ago

Secure boot more or less prevents rootkits entirely

autoexec 3y ago
Except when it doesn't https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/ https://arstechnica.com/information-technology/2023/03/unkil... thanks to UEFI. There have been previous issues as well https://www.bleepingcomputer.com/news/security/microsoft-fixes-secure-boot-bug-allowing-windows-rootkit-installation/ https://www.bleepingcomputer.com/news/security/microsoft-fix...