SOLVED UEFI boot advantages vs. classic boot loader?

[ChrisRJ]

Hi,

Perhaps I missed something "big" here. But having been "socialized" with hard disks in the 1990s (anyone remember the OS/2 Warp boot manager?) the UEFI approach seems rather complex. Any thoughts on this?

Thanks!

 

[Patrick M. Hausen]

I think UEFI is dead simple. Finally! A FAT partition on which every OS on the system can drop its bootstrap code. Perfect solution.
And you can even put firmware upgrade tools etc. there and invoke them from the EFI shell.

 

[IOSonic]

Yes, please go UEFI, you won't look back.

1. UEFI doesn't just apply to disks, but there is a close (though not 1:1) relationship between disk partitioning scheme and boot method. I'm going to assume going UEFI means you'll want to use GPT disks, and that has multiple advantages over MBR disks including recoverability, partition number and max partition size.

2. Multiboot, multiboot, multiboot. As Patrick just implied, multiboot is easier to effect on EFI and done in a much more standardized way. With MBR scheme, some OS's had some pretty insane ways of calling boot code (Apple, I'm looking at you), and would constantly try to take control of the boot sector with every upgrade or disk check. Coexistence is much more peaceful and standardized in EFI world, from what I have seen.

3. As Patrick said, the ability to inject or launch your own utilities, custom boot managers & drivers is dead easy on EFI.

Some of this is anecdotal and originates from personal pain caused by manufacturer solutions to limitations of BIOS-MBR (hybrid MBRs...), but I think there's every reason to choose the alternative.

All motherboards that I've come across thusfar support operating in BIOS mode, hybrid mode and UEFI mode, so whichever you choose, you'll be able to continue booting your current devices.

 

[Patrick M. Hausen]

I have this small netbook where I have a Windows installation on the original MMC and FreeBSD and Haiku OS on the M.2 SSD I added later. System boots into rEFInd on the SSD EFI partition which then calls FreeBSD EFI loader or Haiku EFI loader from SSD or Windows EFI loader from MMC. Managing these is as simple as dropping some files on a FAT partition.

 

[ChrisRJ]

Thanks a lot, @IOSonic and @Patrick M. Hausen

 

[awasb]

Well ... usability and "simplicity" are not the only things to consider. (Apart from the fact, that it depends what you think is usable and simple.)

1.) INTEL had the "idea" of EFI back in 1998, when nobody _really_ needed it. (As nobody does today. I dare say, Itanium is dead. ) They said it would be more "modern" and more "straight forward" than good ol' legacy bios. (The "foundation code" AKA TianoCore is found here: https://www.tianocore.org ... if only part of it is open source, it's closed source. )

2.) Three years ago INTEL announced "ModernFW". Maybe TianoCore wasn't that modern and straightforward? Seeing is believing ...

3.) And now the FUD stuff ... : (U)EFI is a modular design. It opens gates (pun intended) to malware attacks and hijacking. That was a well known fact. But fancy modular designs were trendy those days. (Just as much as the all growing "firmware" blobs.)

4.) In the good old days(TM) long gone by one had a motherboard and a cpu. The motherboard incorporated a bios. That's it. If you had to boot from network there where dhcp-modules for your nics. If you had to boot from SCSI, there was a SCSI module. Any legacy bios was sufficiently modular. Today? Every CPU comes with two blobs: one for the microcode, one for the ME (that embeds another CPU with os kernel and some user space modules). (U)EFI with some more modules. WIFI-chips, controller boards, nics, even keyboards and mice come with "firmware" blobs. Oh. Almost forgot ... the mainboard gets another ME with it's own "firmware" ... and within those devices are even more "firmware" components for controlled "sub features", that no admin can even have a look at. It's a bit like that flat-earth joke: "firmware" and modules all the way down.

5.) There are no standardized update strategies, trust issues with crippled cryptography instead ... Speaking of cryptography: "Secure transactions" for online banking, ok. Hardened communication between governments, well, yes. But between my printer and my desktop? My rack and my monitor? Even the lanes between the host-CPU-part(s) and the ME are encrypted. In my humble opinion it's absurd hipster bullshit and a waste of energy. What's even more concerning: cryptography is a "moving target". If a certain algorithm is broken, it's not just that one online banking app v2.1 that's coming down. AMD even did crypto lanes between hypervisor and VMs, RAM encryption etc. etc. etc. Instead of designing things properly, everything gets declared "unsafe" or not trustworthy. I'm not in a war with my systems. I just want them to function once configured (and maybe even tuned). No blobs or external "help" needed. (And even if it "could" be needed: I wanted to have a choice.)

Stay away from UEFI as long as you can! “Satan himself masquerades as an angel of light.”

p.s.: The same applies to systemd under linux ... I want orthogonality.

 

[awasb]

Concerning No. 3 above ...

The Far-Reaching Consequences of LogoFAIL

LogoFAIL by BINARLY: Discover how vulnerable image parsing impacts device manufacturers in the UEFI firmware ecosystem. Learn about critical LogoFAIL consequences.

binarly.io