[TUHS] Re: Question about BSD disklabel history

[Dan Cross <crossd@gmail.com>]

On Tue, Jan 2, 2024 at 10:33 PM Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote:
> > On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy <lm@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
>
> [Ted's excellent history of ACPI/UEFI elided for brevity.]
>
> 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.

Warner corrected this: UEFI remains resident and callable.

> 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

I'm well aware.  :-)  But I'll see your LinuxBoot and raise you this:
https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-not-to-open-it-the-need-for-holistic-systems/

Of course, we at Oxide have the luxury of controlling the hardware in
addition to the software that runs [directly] on it, so we can get
away with doing our own thing. It's not so easy in the larger world,
where integrating components from disparate vendors demands _some_
kind of interface. It's just unfortunate that UEFI is the interface
that we got; see also Mothy Roscoe's OSDI'21 keynote about
rediscovering hardware.

> 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; caveat the details that have already been mentioned about
coreboot/oreboot/holistic boot vs LinuxBoot (which replaces the UEFI
DXE layer). However, note that the ACPI spec has fallen under the
auspices of the UEFI forum for the last ten years or so, which is what
I meant (e.g., that one finds the ACPI spec on uefi.org). It's true,
though, that I was being unacceptably imprecise by not mentioning the
history at all and that ACPI came before UEFI.

        - Dan C.