3 Jan
2024
3 Jan
'24
9:57 a.m.
On Tue, Jan 2, 2024 at 8:33 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross
wrote:
Not quite. EFI was the second system. It didn't try to retain any backwards
compatibility with the original IBM BIOS. It was completely different. Early
Intel macs used it to boot. Intel and Apple worked on it together. Intel
wrote it
for the Itanium IA64 fiasco because it couldn't use the IBM BIOS interfaces
and such to boot its new machine because IA64 lacked many of the low-level
tricks that you used to interface. to the BIOS. It was an attempt to redo
things
from scratch.
Intel did then turn it over to something more public to manage, but it was
well on
its way to being an insane mess before it morphed into UEFI. But even in EFI
times it was clearly on the way to being the trainwreck it became.
On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy
<lm(a)mcvoy.com> wrote:
Ironically, the UEFI people have done something _similar_ to OF in the
form of AML (ACPI Machine Language), which is a byte-code
serialization ASL (ACPI Source Language); presumably that's system
independent. The idea of a p-code representation is about where the
similarity ends, though: AML exposes a mechanism to talk to the UEFI
OS for a whole slew of stuff, which is rather unlike what OF did
ACPI (Advanced Configuration and Power Interface) predates UEFI. ACPI
was released in 1996, and was originally intended to be a replacement
for APM (Advanced Power Management). With APM, the OS would crowbar
itself into x86 Real mode in order to call into the APM BIOS in order
to suspend the laptop, fetch power management events from the APM,
etc. Later on, APM grew 32-bit protected mode interfaces, but
effectively, the OS would completely lose control of the thread of
execution while running APM BIOS code, which made life "exciting" for
OS engineers.
So ACPI was originally intended to solve a problem, where the OS could
incorporate a byte code interpreter to do those things that would be
very hardware specific (for example, how to diddle the various random
I/O ports on a HP laptop to bring the perpipherals into a low power
state, which of course would be completely different on a Dell or IBM
laptop. Previously, the APM bios was the abstraction layer; ACPI was
the new abstraction layer.
UEFI came later. UEFI was the second system disease replacement for
EFI (extensible firmware interface), which Intel had developed. EFI
was an implementation that attempted to retain full backwards
compatibility with the de factor standard originally established by
the IBM BIOS. UEFI was an attempt to completely rework the interface
between the OS boot code (which before would talk to the BIOS
interface) with the all new singing, all dancing UEFI interface.
Being a second system, of course it was made horribly complicated, so
as to meet all of the requirements that might be dreamed up by the
industry committee that put it together.
Normally, once the OS has gotten to a certain point in
its OS
initialization, the OS can "terminate UEFI services". At that point,
the OS can no longer call into the UEFI functions --- but it also
doesn't have to worry about the UEFI code servicing an interrupt take
taking control of the CPU away from the OS.
There's a 'however' here. The OS may call UEFI Runtime Services from
time to time (to interact with non-volatile variables), and it has to
carefully
arrange things to do this (it has to swap in a special memory map, etc). So
UEFI isn't completely gone away.. You just don't have to worry about it
fielding interrupts after you exit boot services.
However, the OS can still execute various ACPI
functions, assuming the
OS has its own AML interpreter. (Of course, the UEFI BIOS has its own
AML interpreter --- and scheduler --- and everything else that a
simple OS might have.) Ron Minnich has a number of really good
presentations about the "joys" of working with UEFI. See the YouTube
video, "Replace your Expoit-ridden Firmware with Linux"[1] and prepare to
be horrified about what horrors lurks in the heart of UEFI....
[1] https://www.youtube.com/watch?v=iffTJ1vPCSo
So you can very much be *not* using UEFI, and still be using ACPI ---
either if you are using a pre-2004 computer, or if you are using a
more modern platform which uses LinuxBoot.
Indeed. I got to deal with all of that, and more. I have finished writing
LinuxBoot support for FreeBSD. The normal kexec-tools, u-root, etc aren't
sufficient for FreeBSD because FreeBSD's kernel expects the boot loader
to setup a number of meta-data items that go with the kernel that include
all the information about the system that the kernel simply can't get once
you've entered long mode...
Even with LinuxBoot, you are booting with UEFI, albeit with a much small
much smaller UEFI. The PEI is still there (the pre-efi initialization phase:
that runs the CPU vendor's binary blobs, and does other baisc bringup
of the machine). In addition, UEFI's runtime services remain. Linux's EFI
capsule replaces almost all fo the DEX drivers, though, which is a huge win
It's a stub that acts as the first EFI program that runs before UEFI gets
too
far along (MDS on x86, Shell,efi on all the others). It completely takes
over,
modulo the callbacks to Runtime Services.
Why am I on about Runtime Services so much? That was one of the pain
points of my port. ExitBootServices had been called, and SetVirtualMapping
had been as well by the time my boot loader got to run. So I had
to pass all that into FreeBSD's kernel (along with an interesting amount
of metadata to work around chip errata) and the FreeBSD kernel expected 1:1
PA:VA mapping, but the Linux kernel doesn't do that and if I want to run
there I have to cope. Thankfully, the kernel only needed one bug fix and
two asserts removed to work...
So even with LinuxBoot you still have a tiny bit of UEFI left behind...
Though
the huge ugly mess of it finding what to boot, executing another boot
loader,
and that loading the kernel is thankfully gone.
My BSDcan talk, my EuroBSDcon talk and a forthcoming article on
booting FreeBSD in a LinuxBoot environment are all on this.
https://2023.eurobsdcon.org/slides/eurobsdcon2023-warner_losh-kboot.pdf
are the slides, but the videos aren't up for some reason.... It was very
eye-opening doing this work...
Warner