
UEFI boot: how does that actually work, then? (2014) - luu
https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/
======
mindslight
> _And no, Secure Boot itself is not evil. I am entirely comfortable stating
> this as a fact, and you should be too, unless you think GPG is evil_

Actually no, secure boot _is_ evil, and comparing it to GPG is fallacious. The
objection isn't to code signatures in general, but the inevitability of baked-
in privileged keys inherent in its design. Calling it just an impartial
mechanism is flat out naive, and the author even goes on to describe why:

> _But it’s worth noting it’s no more bad or wrong than most other major ARM
> platforms. Apple locks down the bootloader on all iDevices, and most Android
> devices also ship with locked bootloaders._

While Microsoft exempts x64 hardware because they're concerned about further
anti-trust action, the ARM ecosystem actually demonstrates the end result. By
providing these companies the _capability_ to lock things down, they
inevitably _will_ use it to enforce their inherent authoritarianism onto their
customers. The majority of their customers will not care, accepting the age-
old excuses for authoritarianism like "security". But capturing a pragmatic
majority does not make something _right_ , as apparent to anybody who
struggled due to Microsoft's monopoly in its heyday.

A freedom-preserving boot verification specification is definitely possible.
In such, there must be no privileged key that cannot be disabled or augmented.
Microsoft's x64 requirements do fulfill this, but as a result cause the system
to fall to evil maid attacks. However, evil maid attacks can be prevented by
incorporating an open-to-all proof-of-work / timed-lockout scheme. The core
specification must incorporate this type of non-privileging scheme as a
_required_ element, to preempt any contractual requirements like Microsoft's.

~~~
mwfunk
I can see why you as a consumer might not want hardware that you can't install
custom software on. I can see why it might not be the best solution for
legitimate non-nefarious engineering problems as well. What I've never related
to, however, is the application of a moral dimension to someone selling such a
thing.

I'm all in favor of pragmatic arguments for openness and hackability for the
sake of good engineering, transparency, generosity, customer expectations,
etc. Those are all good things. I've never gotten the sense that the absence
of those things are necessarily evil, however. You clearly do, based on your
choice of words.

Maybe that's the difference between the (for lack of a better term) BSD
philosophy vs. RMS. The BSD (permissive?) philosophy seems rooted in the sense
that sharing is a virtue, and not sharing is neutral (not necessarily evil).
RMS' philosophy has always felt like, sharing is neutral, and not sharing is
evil.

It's a gross generalization, but copyleft vs. permissive reminds me of western
vs. eastern religions. The FSF philosophy is defined by a large number of very
strict thou shalt nots, defined as carefully and precisely as possible.
Permissive licenses like BSD/MIT/Artistic/Apache/etc. are defined by their
lack of conditions, which usually just amount to "do whatever you want, but
you can't sue the author".

Similarly, one of the ways western vs. eastern religions (from the outside
looking in, at least) feel different is the focus on not being evil, by being
aware of all of the behavioral laws you shouldn't violate, vs. the focus on
trying to attain enlightenment by trying to elevate yourself. Stamping out bad
behavior vs. encouraging good behavior. I see the merits of both, but for
whatever reason the latter has always been much more relatable for me. I
wonder if an individual's preference of copyleft vs. permissive is correlated
with whether they think humans are inherently evil, vs. humans being
inherently good or neutral. As cynical and pessimistic as I feel about
humanity sometimes, deep down I do have a conviction that people are
inherently good. It might be naive but I've never been able to totally shake
it.

~~~
mindslight
> _Maybe that 's the difference between the (for lack of a better term) BSD
> philosophy vs. RMS_

I like your characterization of this, but keep in mind you're proceeding to
apply a moral dimension here ;)

> _I wonder if an individual 's preference of copyleft vs. permissive is
> correlated with whether they think humans are inherently evil, vs. humans
> being inherently good or neutral. As cynical and pessimistic as I feel about
> humanity sometimes, deep down I do have a conviction that people are
> inherently good._

Most people have an internal narrative whereby they are doing good, yet we
still get emergent evil behavior. I tend to look at good/evil in terms of
describing constructive end results, rather than as intent behind individual
actions.

Pragmatically, I'm seeing an awful lot of Free software that has been locked
down through one scheme or another, making it non-Free for its end users.
Since the intention of at least some of this software was to be Free for end
users, I'd say nullifying that goal is moving in an evil direction.

While fewer restrictions is indeed "simpler", such a regime isn't necessarily
sufficient to achieve certain goals. When something is existentially defined
as "base primitives", complexity will build on top of it to undermine the
goals that fostered the axioms. Only by defining universal quantifications on
behavior can specific qualities be preserved through time.

------
userbinator
IMHO UEFI is an overly complex solution that seems to be optimised for
multibooting in various complex ways, a use-case that is probably _extremely_
rare; how many "average users" do you know which have more than one OS
natively installed on their machine? And of those, how many have more than
two? Especially in this era of VMs, multibooting is becoming increasingly
rare.

On the other hand, BIOS boot is optimised for the overwhelmingly common case
of one OS; select a boot device, load its first sector into memory, and jump
to it. The BIOS does not need to know at all about filesystems, partitioning,
or other things which are more at the OS level, which I think is a good
application of the principle of "separation of concerns"; UEFI however seems
to have become much of an OS itself, with all the associated complexity and
increased failure modes of such. Two memorable incidents:

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

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

 _There is no BIOS specification. BIOS is a de facto standard – it works the
way it worked on actual IBM PCs, in the 1980s. That’s kind of one of the
reasons UEFI exists._

It's more like a collection of specifications, but you can find much of the
important ones here and much of the API is in the _IBM PC /AT Technical
Reference_:

[http://cs.dartmouth.edu/~bx/blog/resources/bios.html](http://cs.dartmouth.edu/~bx/blog/resources/bios.html)

The particularly relevant one for this article is here:

[http://www.phoenix.com/resources/specs-
bbs101.pdf](http://www.phoenix.com/resources/specs-bbs101.pdf)

(Note the URL and the date of the document.)

 _The design doesn’t provide a standard way of booting from anything except
disks. We’re not going to really talk about that in this article, but just be
aware it’s another advantage of UEFI booting: it provides a standard way for
booting from, for instance, a remote server._

Network booting in the BIOS world is almost always done through PXE.

~~~
drvdevd
Thats interesting. I've booted UEFI machines using PXE and judging from the
PXE ROM versions displayed, the PXE code hasn't changed much, on my boxes at
least.

I would agree that UEFI _is_ an OS of its' own. But thats the whole point
isn't it? That way writing drivers for peripherals can be done in C, etc.

I have a BIOS machine I cant boot using my SD card for example, which I need
to do. I imagine writing (or porting) a driver for UEFI to interface with that
SD card reader would be an order of magnitude simpler than doing the same by
modifying my BIOS (which I've seriously considered doing).

~~~
kijiki
The BIOS way to do this is with an Option ROM. During boot, the BIOS scans for
a special signature, and jumps to a fixed offset in that block. The OPROM init
routine then hooks the various software interrupts that the BIOS, boot-loader
and other OPROMs use to read from disk.

You can inject a custom one into your BIOS image, but if you have PCI/PCIe
available, you can get cards that have an OPROM onboard. The easiest/hacky way
is an old NIC that someone has reverse engineered enough to flash its OPROM;
you're just using it for the OPROM, the NIC functionality is unused.

~~~
drvdevd
Very interesting thank you. You may already be aware, but when I first saw the
replies here mentioning Option ROMs I immediately thought of the thunderstrike
EFI vulnerabilities for Macbooks. I've yet to actually mess with them, but
apparently that was how they worked at least in the first generation, I
haven't followed the research much further yet
[[https://trmm.net/Thunderstrike](https://trmm.net/Thunderstrike)]. So since
option ROMs, for obvious reasons, survived the "transition" to EFI, does this
mean the same mechanism could be used in BIOS machines? At least this might
also have implications for backporting peripheral drivers too (for whatever
reason)...

------
Peaker
Excellent summary.

A decade ago I was very well versed in how the bits and bytes of the MBR,
partition table and BIOS boot process worked.

Since then, I was completely out of the loop, and this filled me in.

------
boostedsignal
I wrote a 5-minute tutorial on this (would appreciate feedback):
[http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1c...](http://www.boostedsignal.com/blog/a28c2988-151e-42cd-b0ab-1ce73bafa714.html)

~~~
no_protocol
I like how it is concise and still seems to get the important points across.
Well done.

~~~
boostedsignal
Thank you! That was my goal. I banged my head so much against the wall trying
to understand the process, even though it should have been conceptually
simple. If there are other topics (not necessarily computer-related) that you
feel might benefit from a short explanation as well, feel free to let me know,
and if I know about them I'd love to write about them.

------
AceJohnny2
_> Unless you’re dealing with Macs, and quite frankly, screw Macs._

See also yesterday's story about the 2016 MBP not supporting Linux...

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

~~~
jlgaddis
You mean yesterday's story about Linux not supporting the latest MacBook Pro?

~~~
AceJohnny2
Yeah, that. Oops, looks like my phrasing got me downvotes. Oh well.

~~~
duncan_bayne
It got an upvote from me, for what that's worth.

------
jaclaz
With all due respect for the Author (the article is seemingly a very nice one)
there is the everstanding confusion between disk and partition/volume. I had
hoped that - particularly for something intended to explain things - I would
have had not to read "format a disk". Just in case, a disk is partitioned (in
either MBR or GPT "style"), and the partition(s) or volume(s) on it thus
created are later formatted with a given file system.

~~~
wereHamster
You can certainly format a whole disk. I did it, the disk in my laptop doesn't
have a partition table at all. The whole disk is one big encrypted filesystem.
The laptop boots off of an external USB stick.

~~~
jaclaz
Sure you can, but that disk won't be bootable in UEFI (it may still be in
BIOS). The article is about UEFI booting, with parted he checks the
partitioning "style", not the actual formatting. >See that Partition table:
msdos? This is an MBR/MS-DOS formatted disk. If it was GPT-formatted, that
would say gpt.

------
laacz
Read was interesting, but I found myself pushing through by force of
curiosity. It was hard, since the post itself was very agressive to me - the
reader.

------
Avernar
The flaw with UEFI is that the list of installed operating systems is stored
in the motherboard's NVRAM and not in the EFI system partion on the disk
itself.

When your motherboard dies and you need to put in a new one, now you have to
boot off a CD/DVD/USB Stick to get to the boot manager utility. Then you have
to figure out the command line parameters since the first time the OS
installer did it for you.

At minimum the motherboard setup menu should give you FULL editing cabability
of the NVRAM variables. I should be able to add, modify and delete any and all
entries without having to boot something first.

Last motherboard I tried using the efibootmgr on got bricked. And there was no
way to clear it like you can with normal BIOS NVRAM.

~~~
rwmj
This is nonsense. UEFI has a fallback path and all common OSes can or do
install a fallback bootloader which restores the NVRAM variables.

~~~
Avernar
You may not agree with me but don't call it nonsense.

From the article about the fallback path: "This mechanism is not designed for
booting permanently-installed OSes."

Plus there is only one fallback path so we're back to the situation of
multiple OSes fighting over the fallback path.

And from the article a disadvantage of the BIOS: "It’s inconvenient to deal
with – you need special utilities to write the MBR, and just about the only
way to find out what’s in one is to dd the contents out and examine them."

But now with UEFI we need a special utility to manipulate the EFI NVRAM
variables. The motherboard setup only lists the names of the entries. No
editing and no listing of the details.

So my criticism is valid. The information stored in the UEFI bootmanager NVRAM
should have been in a file(s) in the system partition.

------
ciupicri
2014

