
“Last Mile” Barriers to Removing Legacy BIOS [pdf] - okket
http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf
======
userbinator
This is sad. _Very_ sad. It means "PCs" are only going to become more closed
and proprietary than ever before, at an even faster rate.

"Legacy" is a _good_ thing. It means simple, stable interfaces that have been
around for long enough to be mature, well-understood, and relied upon by
everyone. Some examples: A PS/2 mouse or keyboard doesn't require a full USB
stack in order to work, nor can it exploit the system by becoming a different
USB device and sending malformed packets. RS232 is simple enough that it's the
de-facto "standard input/output" on embedded platforms. LPT/IEEE1284 gives you
8 bits of GP(I)O with ultra-low latency (microseconds vs milliseconds for
USB.)

It's disgusting to see the "security" argument brought up again here, when
it's all about corporate control over the users. To them, it's a "security
risk" to not have secure boot. To the users, it's freedom.

The "advantage" of "smaller code size" is complete FUD. I'm pretty sure the
ROM images have gotten much bigger since UEFI became the norm, composed of
bloated compiler output instead of the beautifully efficient handwritten Asm
that BIOSes used to be written in.

 _No DOS requirements for pre-OS validation /tools (try UEFI Shell or Python)_

DOS is simple, which is why it remains so common for BIOS flashing, testing,
etc. Replacing that with the horrendous bloat of UEFI Shell or Python!?!?
Yuck!!

Linus Torvalds' famous rant is well worth reading:
[http://yarchive.net/comp/linux/efi.html](http://yarchive.net/comp/linux/efi.html)

tl;dr: You can pry 7c00h and INT xx from my cold, dead hands.

~~~
Rusky
Secure boot doesn't mean the user isn't allowed to replace the bootloader or
kernel, and it _is_ more secure.

UEFI doesn't require USB or secure boot or a compiled language or Python or
proprietary code.

It would be nice to have something simpler than UEFI to replace the legacy PC
boot process, but the point IMO is that _we want to replace the legacy PC boot
process_. It's not as straightforward as "simple, stable interfaces that have
been around for long enough to be mature, well-understood, and relied upon by
everyone." It's a de-facto standard with a lot of room for things to go wrong,
and they do.

~~~
userbinator
_Secure boot doesn 't mean the user isn't allowed to replace the bootloader or
kernel_

Unfortunately that's what it will likely turn out to be in practice.

 _It 's a de-facto standard with a lot of room for things to go wrong, and
they do._

...as opposed to an even more complex standard? The saying about "known
unknowns" and "unknown unknowns" comes to mind... there is literally tons of
documentation out there about all the "legacy" devices in a PC, but far less
about the newer proprietary bits.

~~~
johncolanduoni
> Unfortunately that's what it will likely turn out to be in practice.

Even Microsoft specifically forbids hardware marked as "Windows compatible"
from not allowing user installed keys on x86. I'd like some actual reasoning
for "likely".

~~~
Santosh83
Okay so how is an 'average' computer user supposed to install a Linux OS that
they want (or another OS) on their PC without reading up on MoK keys and UEFI
and delving into the key management interface?

Yes, you _can_ install the few 'blessed' distros like Ubuntu, Fedora or
OpenSuSE, but what about distro X? Thus far, an average user need only pop a
CD to install Majaro or FreeBSD or FreeDOS. Now...? Install their own keys?
Sign their kernels and modules?

This reminds me of all the anti-piracy measures. Sure, you can theoretically
circumvent all the DRM. But is it practical for 90% of users? No.

Sure, DRM is theoretically perfectly fine, as is Secure Boot. As is even ME.
The theory is always fine. How it turns out in practice, not so much. We
should be asking ourselves if this marked disparity is really just
inadvertent.

~~~
Rusky
Woah, wait. DRM and the ME are _not_ fine in theory. Secure boot is.

If the practice of installing your own keys is too hard, that's something we
can fix. We can't fix DRM or ME without just removing them.

~~~
betterunix2
Secure Boot is part of an effort to harden DRM on PCs; this is something
Microsoft and Intel have pushed for over a decade, especially now that they
have seen how much money is being made on mobile devices (where DRM was baked
in from the beginning). There is not much benefit to users, because bootloader
malware was never a major threat and malware remains a constant threat for
users despite years of Secure Boot deployment (just the other day my mother-
in-law asked us to deal with a ransomware'd surface pro). The real point of
Secure Boot is to create a system where users do not have the freedom to
install arbitrary software i.e. where all software must be installed from an
app store, where it can be vetted to ensure that it does not allow users to do
things like breaking DRM systems or blocking ads.

------
kev009
UEFI is a great example of second system syndrome. In the BIOS world, more
featured boot loaders were chained in early (think pxelinux, grub, *BSD
loaders etc) so even though it was primitive it wasn't the typical UX. UEFI is
almost trollingly bad, the worst amalgamation of low level firmware, boot
loader UX, and OS->firmware runtime services I've seen when contrasted to
OpenFirmware, uBoot, petitboot.

OpenFirmware was a much more elegant technology sitting around for the
lifetime of modern x86 but intel had to be different.

I like the direction IBM is going with OpenPOWER.. petitboot/kexec by default
[https://sthbrx.github.io/blog/2016/05/13/tell-me-about-
petit...](https://sthbrx.github.io/blog/2016/05/13/tell-me-about-petitboot/)
although all the firmware sources are on github so you could do whatever the
heck you want. It makes intel look positively oppressive.

~~~
wolfgke
> OpenFirmware was a much more elegant technology sitting around for the
> lifetime of modern x86 but intel had to be different.

Let's rather look at the reasing of the UEFI developers why they have a
different opinion on Open Firmware (page 5 of
[http://www.uefi.org/sites/default/files/resources/A_Tale_of_...](http://www.uefi.org/sites/default/files/resources/A_Tale_of_Two_Standards_0.pdf)):

"Another effort that is similar in its role to the PC/AT BIOS-based platform
occurred with Open Firmware (OF) [4] and the Common Hardware Reference
Platform (CHRP). CHRP was a set of common platform designs and hardware
specifications meant to allow for interoperable designs among PowerPC
(PowerPC) platform builders. Open Firmware, also known as IEEE-1275 [4], has
issues in that it is an interpreted, stack-based byte-code. Very few
programmers are facile in Forth programming, and it is renowned as being
“write-once/understand-never”, and having poor performance, and non-standard
tools. Also, Open Firmware has a device tree essentially duplicating ACPI
static tables. As such, the lack of Forth programmers, prevalence of ACPI, and
the fact that UEFI uses standard tools and works alongside ACPI — versus
instead-of — helped spell Open Firmware’s lack of growth. In fact, it is used
on SPARC and PowerPC, but it is unsuitable for high-volume machines and thus
prevent it from making the leap from niche server & workstation markets."

~~~
kev009
That is almost entirely FUD, every Mac before the intel switch had
OpenFirmware. FCode was elegant in that it is cross platform, and the option
ROMs can work across multiple uarchs. The only valid point is that Forth is
obscure. I don't know how much that matters in reality due to how obscure
working at that level is itself, as an OS dev you're working on the device
tree and runtime services in a language like C. But I will grant benefit of
the doubt since I'm an OS dev and not an option ROM dev.. and say, well,
Petitboot is the logical endgame as the industry has made Linux uber alles and
you're going to be writing drivers for it anyway.

~~~
monocasa
Also, if it was really an issue, you could just compile something else to
FCode. Pretty much every non-native language is being compiled first to a
stack language that looks a lot like a shitty version of Forth as the IR.

~~~
wolfgke
> Pretty much every non-native language is being compiled first to a stack
> language that looks a lot like a shitty version of Forth as the IR.

It is not clear what you mean with that. I assume you want to hint that the
CLR and the Java Runtime use a stack-based instruction set and are common
compilation targets, which is true.

But there are lots of other virtual machines that provide a runtime that are
not stack-based. For example the implementation of the Lua 5.0 runtime is
register-based. An other example of a register-based virtual machine is
Parrot.

~~~
foota
I believe that many compilers have an intermediate step that looks like a
stack based language.

~~~
jcranmer
Compiler IRs are often based on reflecting expression DAGs rather than
manipulating a finite register set or an infinite stack.

~~~
exikyut
Manipulating an infinite stack sounds like a _really_ big world of pain.

I realize you're only ever poking around near the top, but if the system has
the chance to grow infinitely, well, it will.

------
bobcallme
My main concern with this is the fact that if Secure Boot is forced (UEFI
Class 3/+) users might not be able to change or manage trusted keys. It is
quite sad that every few years we have to yet again have this conversation or
defend the right to freely install software on machines that we bought or own.

~~~
colemickens
A concern that has been repeated for 5+ years at this point, and one that has
proven to be almost completely unsubstantiated by any real world devices.

Don't get me wrong, the day I can't install Linux on my laptops, I'll grab the
pitchforks, but the claims that this is going to happen almost exclusively
hinge on some boogeyman ideology related to Microsoft that is fully
unconvincing to me.

edit: Please, tell me a single consumer laptop that doesn't allow key
enrollment or complete Secure Boot disablement, otherwise, please stop with
the FUD.

~~~
joe_the_user
I may not be especially competent but I had significant difficulty installing
Linux the last time tried.

Thankfully it was possible but there are now significant hurdles. That's
problematic. Whether it gets worse is unknown but the situation now is bad if
anyone wants Linux to be freely available.

~~~
colemickens
Can you elaborate on the "significant hurdles"? I've heard this before, but it
never comes with any specifics - examples, error messages, forum posts,
_nothing_. If nothing else, if there is seriously a manufacturer that is
botching their implementation, please tell the community so that we can avoid
them.

I've installed Linux on dozens of laptops. Here are the "significant hurdles":

1\. Literally none, because mainstream distros are signed and boot under
Secure Boot

2\. Literally a single toggle in the BIOS to disable SecureBoot. (Enrolling
user keys is more steps, but optional)

And then since most people really mean "UEFI" or other miscellaneous
compatibility problems when they say SecureBoot:

3\. Literally a single toggle in the BIOS to enable CSM mode for
distros/install media that don't support UEFI.

4\. Laptops that ship with the SSD in RAID mode (only very, very new kernels
ship with support for it). I've only heard of one laptop that didn't allow it
to be toggled and it was fixed within two weeks.

~~~
smichel17
I observed a friend's computer that shipped with no hotkey to access the BIOS
settings or boot menu. In order to get into the computer to boot to a usb
drive for installing Linux, you had to either accept the Windows license
agreement or disassemble the computer and pull the hard drive.

~~~
digi_owl
The laptop i am tying this on supposedly had a "BIOS" key combo, but i never
got it to work.

What i had to do was hold a key (shift i believe) while clicking restart in
Windows, and then i would get a menu that could take me to the menu...

------
hd4
Sorry to go straight off-topic but if anyone from AMD is reading, please
remove PSP from future and/or give us the ability to remove it from existing
machines, this is a golden opportunity (with the Intel ME having been shown to
be broken recently
[https://news.ycombinator.com/item?id=15656931](https://news.ycombinator.com/item?id=15656931)
) you really shouldn't pass up.

~~~
roblabla
They already said they wouldn't open source it (after suggesting they might).
I doubt they'll ever think about removing it.

[0]:
[https://news.ycombinator.com/item?id=14803373](https://news.ycombinator.com/item?id=14803373)

~~~
monocasa
Being open source doesn't really matter; it's having access to the keys. And
they're never going to give those up because it would break the chain of trust
for their DRM.

~~~
phkahler
I don't want their DRM or their DRMed content. I'll gladly buy a computer for
my own uses that don't have those "features".

------
forapurpose
Helping to secure the boot process is valuable. My main concern about UEFI is
end-user control, and one way UEFI reduces end-user control is through
complexity.

Think of what someone new to IT had to learn 20 years ago about bootup and
compare it to now. UEFI is far more complex than BIOS; IIRC the spec is over
2,000 pages. I'm a professional and I've spent significant time looking into
UEFI, and I don't feel that I really grok the whole subsystem. What is some
kid going to do? And add to that all the other 'new' subsystems in the boot
process, from TPM to ME to AMT to TXT ... someone would need to be a full-time
'boot specialist' to grasp it all, keep up with them, and understand how they
interoperate.

------
ChuckMcM
I find this the inevitable "next step" into more appliance mode that these
machines are moving into. And like tranches of collateralized debt
obligations, harder and harder to figure out exactly what your buying into
when you decide to get one of these machines. On slow days I try to imagine
what I would really "like" here. One of the things I would like would be a
stance on surveillance that would protect me from commercial surveillance that
I had not explicitly agreed to, and a way for individuals to take action
against people who violated that stance.

------
keiyakins
How about 'there's no good replacement yet'? All that the firmware should be
doing is making sure the hardware is intact enough to load the next stage,
then finding, loading, verifying (a the very least, checking signatures for
accidental modification, and ideally checking the keys against ones that
require physically moving a jumper or dip switch to change), and executing the
first on-disk stage. MAYBE initializing a very basic text mode so it can show
errors, MAYBE a halfassed keyboard handler to let you help it out if it gets
confused.

Granted, this does mean it has to have some sort of bus it can use to talk to
various storage devices, but even this should be as simple as possible - you
can switch to a more complex but faster one later, you just need to be able to
load a couple kilobytes.

------
cjensen
There sure was a lot of "people use legacy for specific reasons" in there, but
they don't mention what those reasons might be -- except for Linux support.

Kinda hard to fix the "last mile" when you don't know anything about the last
mile.

~~~
josteink
> they don't mention what those reasons might be -- except for Linux support.

I UEFI boot all my Linux systems.

What FUD are you on about?

~~~
cjensen
If you Read The Fine Article, it says that people disable UEFI for Linux. And,
like you, they point out that secure boot can be disabled instead.

I pointed out that they list zero additional reasons people give for disabling
UEFI, so it is hard to evaluate how to fix the "last mile" for _those cases_.

Calling that FUD when it is literally in the article is unkind at best. I
shouldn't have to reiterate stuff already said in the article in order to
avoid hurting the feelings of Linux users who haven't.

~~~
josteink
> And, like you, they point out that secure boot can be disabled instead.

Why would I do that? All Linux distros I use works fine with Secure Boot.

------
jgowdy
Everyone is bitching about how UEFI makes them not the owner of their computer
anymore, as if they’re using an open source BIOS and ever had any firmware
layer control over their PC.

The fact that you can argue that with BIOS you have control means you don’t
really understand Intel ME and the other firmware components that actually run
your PC. If you want an open platform, Intel and AMD aren’t it. If you want a
modern functional platform, Intel and AMD are it.

This is why I have such high hopes for RISC-V.

~~~
sigjuice
I don't understand how RISC-V will lead to open platforms. Vendors of RISC-V
SoC's will most likely include their own Intel ME type bullshit.

------
Gonzih
I run Linux in legacy mode on my 4 machines. UEFI for me was extra complexity
without any gain. Sad to see that's uefi is gonna be only option in the
future.

~~~
BenjiWiebe
I've been booting with the kernel as an EFI stub, and I love it. I can copy a
new compiled kernel to the right directory, and reboot into it. No grub
involved. And to edit the boot menu, or just change what I'll boot into next,
is the handy efibootmgr tool.

~~~
TheDong
Unfortunately, that means you don't have an initrd so you can't do luks
encryption of your root, support certain filesystems as root (like zfs, mdadm
raid), or various other things.

efistub kernels may work for some people, but they're not a generic solution.

~~~
ronsor
That's totally false. Just yesterday I booted a kernel using the EFI stub and
was able to use an initrd.

------
0x0
Does this mean they're also looking to rip out 16bit real mode support
entirely from their x86/x86_64 CPUs?

~~~
dfox
There isn't much reason to do so. Additional resources needed to support 16bit
modes probably does not exceed few hundred transistors of logic and bunch of
words of microcode. The data path is completely same, there are only few
control differences (loads to selector registers set offset=value<<4;
limit=0xffff; size=16bit instead of consulting descriptor tables).

On the other x86_64 CPU can be significantly simplified by riping out both
16bit and 32bit modes and thus all the selector/descriptor segmentation logic
and replacing IDT with something simpler and less general.

~~~
21
According to Wikipedia Windows 64 bit runs 32 bit apps by switching back to 32
bit mode.

> which switches the processor hardware from its 64-bit mode to compatibility
> mode when it becomes necessary to execute a 32-bit thread, and then handles
> the switch back to 64-bit mode.

[https://en.wikipedia.org/wiki/WoW64](https://en.wikipedia.org/wiki/WoW64)

~~~
dfox
"Compatibility mode" is sub-mode of long mode which has limited support for
16/32b i386-style memory segmentation (notably there is no support for vm86
code segments and gate descriptors have different format and can only
reference 64bit "segments").

It is clear that AMD's intention for this was to implement just enough of
segmentation in long mode to allow compatibility with segment-aware user-space
code (eg. mixed 16/32b Windows userspace) but there does not seem to be any OS
that actually uses 16bit descriptors in long mode (probably due to the
mechanism being significantly different than i386's 16/32 compatibility). For
compatibility with "normal" flat address space user space code the whole
mechanism could be significantly simpler and have same "segmantation" behavior
as 64b mode, have 32b EIP pushed on stack by CALL/RET and trap on anything
that tries to load new selector anywhere (ie JMP/CALL/RET FAR, MOV whatever,
?S), even REX prefix could be supported in such an "limited compatibility
mode" and we would not have to invent things like x32_abi (which is to some
extent the same idea, although with different motivations, ie. run new ABI-
incompatible 32b code in 64b mode to gain access to new registers and
instructions while having 32b pointers and thus reduced memory footprint).

------
sanbor
Floppy disks used to have a tab to lock them (write only mode). The whole
secure boot thing could be solved by having a switch/tab that you would have
to use when you want to make changes to your bootloader. This would fix the
secure boot issue and let us use our beloved BIOS.

In different jobs I have hear coworkers spending several hours dealing with
UEFI in order to be able to install linux or enable multiboot. As a final user
I don't see any added value except for the secure boot. As others has pointed
out here if a malware has enough access to rewrite your boot probably they
could do a lot worse stuff like installing a keylogger, a fake browser,
encrypt/steal your data, etc.

UEFI looks to me like Inte ME. A tech that it might make sense for enterprise,
servers, etc. but not to the final user.

Looking forward to let Intel alone and use more open alternatives but I know
that it is very hard to get the same computing power/features in other
platforms.

------
upofadown
What currently deployed attacks does secure boot prevent? We hear a lot about
secure boot is going to improve security but not a lot about exactly how it is
going to do that. If some sort of malware has the ability to rewrite the
relatively tiny boot stuff it also has the ability to write anywhere in the
operating system.

------
Aardwolf
So does uefi support multi boot or not?

~~~
0xcde4c3db
The standard supports multiple bootloaders, but specific implementations may
be locked down to a single one. Even on systems that support multiple
bootloaders, it's pretty common to bypass the built-in menu in favor of a more
configurable chainloader like GRUB or rEFInd.

~~~
snuxoll
I mean, basically every UEFI implementation I've worked with supports any
number of boot entries - but I'm forced to hit a key during startup to even
get to the menu to select one. All it would take is an option to present a
selection menu every boot (unless the operating system has asked to boot a
specific one during a reboot) and I would set my grub timeout to like 2
seconds with no menu by default.

------
hsivonen
Last I tried, more that 2 years ago, Ubuntu was able to install on LVM over
LUKS over sofware RAID and boot from it in BIOS mode but the result in UEFI
mode completed install but didn't boot.

I wonder if that has been fixed.

~~~
kobeya
Usually it’s because he installer mucks up the crypttab, or doesn’t install
mdadm module, or something. And yes, installing with BIOS usually gets it
right. But it can be made to work with UEFI.

------
agumonkey
Meaning I will migrate all my machines to coreboot.

------
jokoon
I recently disabled secure boot so I could install linux...

I was quite amazed I had to do that to be able to install a system I wanted...

------
shmerl
Why can't there be normal open source UEFI? No one seems to be pushing to get
rid of all these blobs.

------
lousken
> Some users blame UEFI or Secure Boot whenever something doesn’t work

and what else to blame?

~~~
josteink
The words of a true detective.

Like there’s nothing else in the giant mess which is the x86 architecture
which can’t break.

------
dingo_bat
Can anybody point me to a list of problems with "legacy" BIOS that UEFI fixes?
My PCs have had no problem booting in the decade I've been using them. They
boot windows, ubuntu, arch, basically whatever I want them to boot. What's the
big problem?

~~~
betterunix2
Well, consider the situation Blizzard is in with WoW: people who want to cheat
have resorted to writing rootkits to defeat the DRM system. Locking down the
bootloader will help prevent users like yourself from defeating DRM, this
making the platform more secure for entertainment companies.

Sorry, did you think the improvements was for users?

~~~
dingo_bat
> Sorry, did you think the improvements was for users?

Well, funny but sad.

------
maxharris
It's about time this happened! I spent the last decade using computers free of
that BIOS crud (various Macs and now a Surface Pro), and all I can say is,
"good riddance!"

~~~
Thriptic
Surface pro has a BIOS interface, it's just stupidly inaccessible. Their
design also means that you can't easily install your own copy of windows and
are instead stuck pulling down their stupid recovery images whenever you want
to format. I'm very annoyed that they decided to go this direction personally.

~~~
Spooky23
They did that to protect the platform against stupid enterprises.

~~~
Thriptic
What do you mean?

~~~
Spooky23
Office 365 taught them how much corporate testing and imaging hurt their
products.

In one case I’m familiar with, they were getting pummeled over poor O365 user
experience in 2015 because the customer was refusing to upgrade past Office
2007.

Everything they’ve done in the last 5 years is about pushing out software
faster and making traditional enterprise IT too expensive.

~~~
exikyut
Suddenly the push behind cloud makes a lot more sense. Interesting to know.

