[TUHS] Question about BSD disklabel history

[Warner Losh]

On Tue, Jan 2, 2024 at 8:33 PM Theodore Ts'o <tytso at 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 at 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.
>

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.


> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240102/a0b5e85a/attachment.htm>