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