[Oberon] UEFI

[Michael Schierl]

Hello Paul,


Am 24.11.2020 um 16:47 schrieb Paul Reed:
> Hi Liam,
>
>> UEFI is a horror. I loathe it.
>
> Do you mean UEFI, or Secure Boot? I'm interested (and in raising the
> tone a bit). ;-)

In my experience, there are two big obstacles to UEFI adoption.

First, the expectation of some people that it "should just work like the
old BIOS". UEFI deliberately changed some of the "givens" in how an OS
is booted on an "IBM-compatible" computer.

Second, buggy implementations. I am currently writing this email on my
old notebook (ThinkPad L530 bought in 2013) where I know that if I boot
certain UEFI bootloaders (in UEFI mode) and then without a complete
power down boot any BIOS bootloader, my BIOS memory map will reserve
about a dozen megabytes more for "System reserved". Persistently. This
went as far as that I had almost 1.5 GB memory "lost", until I was able
to track it down and fix it (see https://superuser.com/a/762823/1724 for
the gory details if you are interested). You can fix it manually if you
boot into an UEFI shell, but definitely the worst bug I personally
encountered. Other known bugs (that I never encountered, but that does
not make them less severe) are some UEFI implementations that bricked
themselves if the UEFI configuration is too often reconfigured without
rebooting (which can happen if you have a machine that runs 24/7, yet
get the regular kernel updates that rewrite the UEFI configuration, but
you never reboot). And the most embarrassing one is some firmware which
refuses to boot any UEFI boot entry if their name does not equal
"Windows Boot Manager". There are workarounds for all of these bugs, but
it is cumbersome that you have to deal with them (after finding out
which of these bugs hit you).

It is a bit like the siutation with ACPI tables in notebooks in the
early 2000s. It is possible in them to store quirks that depend on the
start of the operating system name. Some models had quirks for "Windows
NT", "Windows 2"(000/003), "Windows ME", "Windows 9"(5/8), and "Windows
XP". To an extent that any operating system that had no quirk for itself
did either not boot or suspend properly, resulting in Linux distros
shipping alternative ACPI tables for common brands (Anybody remembering
websites that check for Netscape and IE and won't work if neither
browser is found? Yes, similar bug) or having tables which OS they need
to identify as when booted on certain systems. Nowadays, when there is
more diversity in Windows installations (not everything is XP, but you
have Vista, 7, 8, 10) as well as more vendors are aware that there are
other OSes around, the situation got slightly better. Yet still this
fiasco was one of the reasons why Windows 10 was not called Windows 9.

Today, about 15-20 years later, nobody insists on disabling ACPI on his
notebooks and use APM for power management instead (as I did on my
second previous notebook, starting from the one I'm currently using).
The same will happen with UEFI in a few years, I believe. The bugs will
hopefully weed out (as vendors start using known-good code from other
vendors instead of writing their own, like they do for BIOS today), and
people will learn the differences and have an UEFI shell on a bootable
USB key handy (like I do all the times) to fix things when the firmware
setup does not provide the options for it, similar to how some people
carry a customized Ubuntu live media (or a Win10 Recovery Drive) today
to fix Windows/Linux configuration and boot issues.

It would even be better if every UEFI just came with a built-in UEFI
shell selectable from the boot menu, but it would probably scare too
many users or make them brick their machine, so I understand that this
won't happen.

> If contemporary UEFI is not a reasonable target for any 3rd-party
> operating systems,

As a person who implemented several tools for UEFI, both loaders that
are booted via UEFI as well as command line tools for the UEFI shell,
both on free software (using GNU EFI) and on Visual Studio, I have to
admit that the programming model of EFI is a lot cleaner than the old
BIOS model, and the quirks needed to work around firmware bugs are less
numerous (but also less well documented).

So I would say, that supporting UEFI is not less reasonable than
supporting the legacy "IBM-compatible" BIOS target.



Regards,


Michael