
EFI Sucks (2012) - turrini
https://plus.google.com/+LinusTorvalds/posts/QLe3tSmtSM4
======
kev009
UEFI is a really unfortunate second system with all the markings of Intel's
internal cultural issues imbued onto it that are hard to not see if you've
worked with intel for any length of time. In the common case of an end user
running an operating system, it's really hard to botch that without being
kicked out of the market in ways that can't be worked around so it wont matter
to most computer users. But UEFI is only a minor improvement over BIOS versus
other industry standards for the people that could reap the benefits of an
open and extensible bootloader in embedded, appliances, and hyperscale --
device manufacturers and operating system developers.

------
majewsky
I'll go against the grain here: I go out of my way to use UEFI over BIOS,
because it Just Works for me.

When I got my first UEFI-using notebook in 2012 (same year as the submission),
things were a bit rough because the Arch wiki did not quite know what it was
talking about, and the Arch ISO was not UEFI-bootable, so you had to use some
trickery to install an UEFI bootloader, but even then, it only took me two
hours to figure out partitioning and install the bootloader.

Since then, stuff has gotten much better. Just recently, I switched my
VirtualBox VMs to use UEFI emulation instead of BIOS emulation because it
allows me to use the well-designed systemd-boot (previously known as
gummiboot) instead of that absurd abomination called Grub 2.

~~~
arghwhat
Now try to install arch to a bootable USB stick from your UEFI booted system,
and see all hell break loose.

I boot UEFI, but it's just so bloody cumbersome and fragile. The entire
concept of having boot configuration in NVRAM is _terrible_.

~~~
jonnypickel
Not to turn this into a support thread but this weekend I tried to install
Arch on a new, UEFI-enabled laptop and I've been stymied so far because I
can't get the laptop to recognize my Live USB. I've built it with Rufus, dd
for Windows, and Easy2Boot all with the same result (no bootable device) even
though it works on another machine. Could it be because I created the USB on a
PC using UEFI?

~~~
majewsky
Huh? I just `dd` the official image onto a USB drive and it works 100% of the
time, with various UEFI-using machines.

(Except for that one Gigabyte mainboard which I returned upon finding out that
its v1 firmware will only boot Windows 8.1. Not even Windows 8.0. There was a
firmware update that fixed the issue, but without a bootable OS, applying it
is a chicken-and-egg problem.)

~~~
jonnypickel
Well then, I guess my problem likely lies elsewhere. Thanks for the reply. :)

And that has to be the strangest "feature" I've ever heard of from a hardware
firm. Was it maybe purpose-built for a bulk order of machines that were going
to be pre-loaded with Win8?

------
swiley
The one thing I really love about EFI on non-macs is that you don't need a
boot loader. You just compile your kernel with an EFI stub and whatever you
want in the initrd and then select it with the firmware GUI.

 _That 's nice_

~~~
abhishekjha
I didn't understand a lot of what you said. Any sources?

~~~
zbentley
The Arch wiki in the sibling comment is a good resource for learning a lot.
I'll try to (over)simplify the short version here:

With the old BIOS-based boot process, the computer (the hardware/motherboard;
not the operating system you ran on it) would, when it started up, look around
for installed operating systems to boot. It wouldn't look too hard: on each
hard disk, it would look in one (or, if you were lucky, four) places for a
specially-prepared segment _outside_ of the data installed by the operating
system. This segment isn't a file or something that you can browse to normally
on the drive (though some things shimmed it so it appeared thus); it's a non-
file special segment _outside_ of the OS's normal data/files. That segment
(well, segments, but still) had to be set up just so otherwise the computer
(BIOS) wouldn't find your OS to boot it. Doing this was often tricky, even
more so when you needed multiple operating systems to be bootable. Doing this
was also pretty inelegant, since if you wanted to stick an operating system on
a sub-partition of a disk, as part of the installation process you had to mess
with data that affected _everything_ on that disk, not just what was in the
sub-partition. It worked, and was simple, but it was the equivalent of being
forced to modify a single central global variable in a software project every
time one sub-part (file, function, whatever) of that project wanted to use a
new library. For an excellent writeup of the gritty details of the BIOS/MBR
startup process, see this document: [https://neosmart.net/wiki/mbr-boot-
process/](https://neosmart.net/wiki/mbr-boot-process/)

UEFI, put most simply, looks around for installed operating systems a lot
harder than the BIOS method did. It does a lot more than that, but the benefit
GP was describing accrues from UEFI being much more capable in terms of
discovery: instead of checking a single global prepared location for bootable
OSes, UEFI can look in the files on the drive and do the intuitive thing:
"looks like these files are part of an operating system; I'll give the user an
option to boot from it".

This doesn't always work perfectly, and there's a lot of complexity (and
criticism) I'm hand-waving away here, but that's the gist of the difference.

Sorry, turned out to be a not-so-short version.

~~~
swiley
If it just did discovery that would be pretty annoying. Most firmware actually
lets you select a file to boot manually, that's what I like.

------
tinus_hn
Many of the issues are just that BIOS is old and stable while EFI and UEFI are
new and immature. There should be a testing suite for UEFI like the CSS Acid
test so there is a baseline of working functionality. But instead the test is
‘does it run Windows’ and that really is only a small part of it all.

------
tscs37
A lot of the painpoints are gone, understandbly, but some still exist.

The biggest suck on EFI is that it uses PE fileformats. I would have liked it
more if it would have just loaded a raw PIC binary or ELF. And not used
Windows Calling Conventions.

~~~
AstralStorm
That is not important. The real bad part is that you still cannot easily load
modules of your own to work around broken setup by mainboard manufacturer or
Intel or boot rom in the device. This essentially causes lock in. Or even
disable some broken modules.

(Security has nothing to do with it, the module can be crypto signed by user
installed key.)

Plus the critical hardware setup documentation is not being released at all.

Another is the use of SMI to communicate with the thing which just does not
play well with a preemptible OS.

Memory map handling is additional badness on top.

~~~
zaarn
That's more of an implementation problem of common EFI vendors, not EFI
itself, sans SMI and mmaps.

------
digi_owl
So more of Torvalds on EFI:

[http://yarchive.net/comp/linux/efi.html](http://yarchive.net/comp/linux/efi.html)

And here he is on ACPI:

[http://yarchive.net/comp/linux/acpi.html](http://yarchive.net/comp/linux/acpi.html)

~~~
raverbashing
Linus spent a lot of energy and Management by Perkele to make sure stuff
worked and kept stable under ACPI. People would submit patches that fixed some
things and broke others, and Linus put a stop to this

I'm not so sure about the ACPI standard, it certainly has some warts but the
main issue seems to be manufacturers who ship the thing once their hardware
manages to boot Windows. Once. And note I said boot, not run.

------
snvzz
There's a lot about it that's bad, but the worst is definitely that it allows
the firmware to keep running after the OS boots, interfering with its normal
operation. Thanks to SMI, the system is non-deterministic: No latency promises
can be made.

~~~
tinus_hn
The same happens with BIOS, that is how many of its settings work.

~~~
snvzz
Yes it does, but that's only of historical value by now.

Sigh, they had one job, and they managed to screw it up, so we do still have
to put up with this.

------
dekhn
Is EFI the system that my newer motherboards use when booting up?

Is he talking about the system that has replaced grub on most of my machines
with a more reliable one that's built into the hardware?

In 2012, EFI/UEFI was pretty unreliable because the implementations were bad
and the software support was terrible. Nowadays, I find it preferable.

------
pankajdoharey
Unfortunately his statement is still valid even after 6 yrs, it is still a
complicated disaster. And it uses Fat32 and PE. An abomination in my view.

~~~
rkangel
FAT32 is a good choice IMO. It's the simplest of the "mainstream" filesystems.

~~~
xxs
correct me if I am wrong but it's still patented by Microsoft. Also time
precision is up to even seconds (i.e. it can not store file stamp 'modified at
10:00:01')

~~~
chungy
> Also time precision is up to even seconds (i.e. it can not store file stamp
> 'modified at 10:00:01')

In the pure form of the file system, yes, but with VFAT (which also adds long
file names, creation time stamps, and access time stamps), the precision is
exactly 1 second increments.

~~~
thriftwy
My main memory of VFAT comes from Windows 95 (or was it 98), I remember that
when you saw this word anywhere, this meant your operating system is now
borked beyond any repair.

------
ttflee
> It's just sad how people always try to "improve" on old standard interfaces
> by then over-designing the improvements to the point where the new interface
> is just overwhelmed by complexity.

Did Linus also criticize the complexity and untested nature of systemd?

~~~
craftyguy
How is systemd an 'interface'?

~~~
thomastjeffery
It's how you interact with daemons.

~~~
craftyguy
Ah, right.

I suppose it could also be argued that the kernel is also unnecessarily
complex as well?

~~~
pebers
Possibly, but a pretty obvious retort is that it's necessarily complex; there
is nothing else to do all the things that it does. Whereas for BIOS and EFI
the argument would be that they should do as little as possible to hand over
to the real operating system.

~~~
garmaine
> but a pretty obvious retort is that it's necessarily complex

I would like to offer, as a counter example, every micro kernel ever.

~~~
zaarn
You mean all those micro kernels that are in widespread use and see huge
market shares?

The closest relative is NT and that is a hybrid, not purely micro. Modular and
hybrid kernels (Linux and NT respectively) offer better external vs internal
complexity tradeoffs; Linux and NT are internally complex since they do all
the hard stuff, micorkernels are externally complex since someone else needs
to do the hard work.

Microkernels will shove this exact complexity elsewhere not make it go away.

~~~
garmaine
The most prolific (non-embedded) operating system on the planet is MINIX, a
micro kernel based OS. On the embedded, medical, automotive, and aviation side
there are plenty of micro kernel OS’s that give Linux a run for its money.
Just FYI.

~~~
zaarn
But is that because it's a microkernel or for other reasons? Crash stability
can be achieved in monolithic and modular kernels too, it's not unique to
microkernels.

------
anfilt
I remembering reading this a while ago. EFI just tries to do too much and thus
is too complicated.

Let alone the concerns that secure boot and other OSes.

------
nszceta
Arch Linux on VirtualBox using EFISTUB

Super simple steps to install an Arch Linux guest on VirtualBox with pure
EFISTUB. No bootloader! Fill in the blanks with
[https://wiki.archlinux.org/index.php/installation_guide](https://wiki.archlinux.org/index.php/installation_guide)

timedatectl set-ntp true

gdisk /dev/sda

# 256 MB partition type EF00

mkfs.fat -F32 /dev/sda1

mkfs.btrfs /dev/sda2

mount -o discard,compress-force=lzo /dev/sda2 /mnt

mkdir /mnt/boot

mount /dev/sda1 /mnt/boot

pacstrap /mnt base base-devel btrfs-progs vim openssh

genfstab -U /mnt >> /mnt/etc/fstab

arch-chroot /mnt

ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime

timedatectl set-ntp true

vim /etc/locale.gen

locale-gen

vim /etc/hostname

vim /etc/hosts

systemctl enable dhcpcd

systemctl enable sshd

passwd root

useradd -m user

passwd user

# /boot/startup.nsh

fs0:\vmlinuz-linux rw root=/dev/sda2 initrd=\initramfs-linux.img

exit

umount -R /mnt

poweroff

------
harijay
Had the same experience with my plastic MacBook from 2007 and I could install
Fedora 27 and Mint using a related program to iso master. Good to know about
ISO master.

Wrote about the process: “The 2007 plastic MacBook lives again with Mint-y
Linux awesomeness” @harijay [https://medium.com/@harijay/the-2007-plastic-
macbook-lives-a...](https://medium.com/@harijay/the-2007-plastic-macbook-
lives-again-with-mint-y-linux-awesomeness-374469cc977e)

------
Samis2001
For this area, my ideal world is one where both the BIOS and UEFI are dead,
replaced by something that is inspired both by OpenFirmware and coreboot.

