From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12005 invoked from network); 3 Jan 2024 03:57:57 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2024 03:57:57 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 86D7B43DE0; Wed, 3 Jan 2024 13:57:52 +1000 (AEST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by minnie.tuhs.org (Postfix) with ESMTPS id 550B443DD2 for ; Wed, 3 Jan 2024 13:57:47 +1000 (AEST) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a279ce3aab9so384301466b.0 for ; Tue, 02 Jan 2024 19:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1704254265; x=1704859065; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9d6kKAfmMd6eKB+WYSwm7ExHzeUnmrCWmny6m5b9GhU=; b=NOaGUCfxPprD6CyknGaCwKITzRzF7T4gfpS3kUgbLfk9rsiet1dU4es8RlHwLYAX0X CfavctfJk9H4oC1RKK/9KRA60YRcLgOs4CE+g7xfJeSf8AtZEN8I0IMnUx9SJstLlb89 KfSPScsaGhHfX8yQCvgA9KwzaHO1vS8EGqeLMXxRxFsloGWklv/QDnhe3CLxQcpz8etv o0ZNV2eVg1qpCJq1YyKtwTNox4+RUmHc9xSJr4INR5tHXVumtgLNM4rTFr6RxAbhrBBY Xr/FO7YmdJ5r4C/pXTA4nEyYGZQ1tHdoQMIY5HC9KaLvFggpsD395vkd70RUUo6igg5c ER5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704254265; x=1704859065; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9d6kKAfmMd6eKB+WYSwm7ExHzeUnmrCWmny6m5b9GhU=; b=qbNFR69GEdYjURsQxUIFlPgJvm7sxweRCmzuE7qp3bTG3HCEDTTszsyZGrZW0fk6GB xyjC/wtQ/vFd4XYZ3inlYW4ciWguSNhogWWX6z/fN9WJxNTABDsDp3q/6AM+oMxT08U5 rDI0q1S+lEf53XYa4yQ9uMOEcDWBFyfNkg6oR7ubW6uhAFWL5/cCGjC1jWUWENO+Ywlf su+txlX1FF0wdwl4rwivcBtZVIrLIwoC/zEOC1yyHX/ANRG8xu/kQToKvYZ70iRahq8P rq9wSJKxPC1DdhWzTxspj/BMdgsvMZ3NycS+0Hipw+LMQaX3D6nJWpXyRZvm7IN9K5Kf L5gA== X-Gm-Message-State: AOJu0YxbSymLVOGbSeKMC+7nawsTvQic83F8542EA2N8TAVKYkfj+jsF kugiYPRLwsEAIuPNYQx7FbEDtH5pmG4iyHUmhMpJ9sKSb76K4/3SYRKn+lasVanLvQ== X-Google-Smtp-Source: AGHT+IEdIgHH7NNVXXGQ5sG900vxi2bTBvL2YGmj/abyRQdCc+IDMSyokKBYiNeJqoDIj4gel9CYLgbTJ1L0bXdaMB4= X-Received: by 2002:a17:906:a050:b0:a26:8eb9:8a32 with SMTP id bg16-20020a170906a05000b00a268eb98a32mr3984262ejb.8.1704254265518; Tue, 02 Jan 2024 19:57:45 -0800 (PST) MIME-Version: 1.0 References: <6470c59f-a1e5-418f-803d-76bcd761f530@tnetconsulting.net> <20231231224649.h45pogxycgkgs673@illithid> <20231231230615.GE19322@mcvoy.com> <20240103033345.GA108362@mit.edu> In-Reply-To: <20240103033345.GA108362@mit.edu> From: Warner Losh Date: Tue, 2 Jan 2024 20:57:34 -0700 Message-ID: To: "Theodore Ts'o" Content-Type: multipart/alternative; boundary="0000000000001a7b71060e029e2b" Message-ID-Hash: JBVDJRNGBEUOLYY5LARRME6LLMNGL7WZ X-Message-ID-Hash: JBVDJRNGBEUOLYY5LARRME6LLMNGL7WZ X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Unix Heritage Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Question about BSD disklabel history List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000001a7b71060e029e2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 2, 2024 at 8:33=E2=80=AFPM Theodore Ts'o wrote: > On Tue, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote: > > On Sun, Dec 31, 2023 at 6:25=E2=80=AFPM Larry McVoy wrot= e: > > > > 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. Earl= y 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 EF= I 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=3DiffTJ1vPCSo > > 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 --0000000000001a7b71060e029e2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 2, 2024 at 8:33=E2=80=AFP= M Theodore Ts'o <tytso@mit.edu&= gt; wrote:
On Tu= e, Jan 02, 2024 at 03:48:28PM -0500, Dan Cross wrote:
> On Sun, Dec 31, 2023 at 6:25=E2=80=AFPM 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

ACPI (Advanced Configuration and Power Interface) predates UEFI.=C2=A0 ACPI=
was released in 1996, and was originally intended to be a replacement
for APM (Advanced Power Management).=C2=A0 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.=C2=A0 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.=C2=A0 Previously, the APM bios was the abstraction layer; ACPI was<= br> the new abstraction layer.

UEFI came later.=C2=A0 UEFI was the second system disease replacement for EFI (extensible firmware interface), which Intel had developed.=C2=A0 EFI was an implementation that attempted to retain full backwards
compatibility with the de factor standard originally established by
the IBM BIOS.=C2=A0 UEFI was an attempt to completely rework the interface<= br> 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 bac= kwards
compatibility with the original IBM BIOS. It was completel= y different. Early
Intel macs used it to boot. Intel and Apple wo= rked on it together. Intel wrote it
for the Itanium IA64 fiasco b= ecause it couldn't use the IBM BIOS interfaces
and such to bo= ot its new machine because IA64 lacked many of the low-level
tric= ks that you used to interface. to the BIOS. It was an attempt to redo thing= s
from scratch.

Intel did then turn it o= ver to something more public to manage, but it was well on
its wa= y 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.
=C2=A0
Normally, once the OS has gotten to a certain point in its OS
initialization, the OS can "terminate UEFI services".=C2=A0 At th= at 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 Ser= vices from
time to time (to interact with non-volatile variables)= , and it has to carefully
arrange things to do this (it has to sw= ap in a special memory map, etc). So
UEFI isn't completely go= ne away.. You just don't have to worry about it
fielding inte= rrupts after you exit boot services.
=C2=A0
However, the OS can still execute various ACPI functions, assuming the
OS has its own AML interpreter.=C2=A0 (Of course, the UEFI BIOS has its own=
AML interpreter --- and scheduler --- and everything else that a
simple OS might have.)=C2=A0 Ron Minnich has a number of really good
presentations about the "joys" of working with UEFI.=C2=A0 See th= e YouTube
video, "Replace your Expoit-ridden Firmware with Linux"[1] and pr= epare to
be horrified about what horrors lurks in the heart of UEFI....

[1] https://www.youtube.com/watch?v=3DiffTJ1vPCSo
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.

<= div>Indeed. I got to deal=C2=A0with 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 it= ems that go with the kernel that include
all the information abou= t 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=C2=A0small
much smaller UE= FI. The PEI is still there (the pre-efi initialization phase:
tha= t runs the CPU vendor's binary blobs, and does other baisc=C2=A0bringup=
of the machine). In addition, UEFI's runtime services remain= . Linux's EFI
capsule=C2=A0replaces almost all fo the=C2=A0DE= X 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 intere= sting amount
of metadata to work around chip errata) and the Free= BSD 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. Thankfu= lly, the kernel only needed one bug fix and
two asserts removed t= o work...

So even with LinuxBoot you still have a = tiny bit of UEFI left behind...=C2=A0 Though
the huge ugly mess o= f it finding what to boot, executing another boot loader,
and tha= t loading the kernel is thankfully gone.

My BSDcan= talk, my EuroBSDcon talk and a forthcoming article on
booting Fr= eeBSD in a LinuxBoot environment are all on this.

are the slides, but the videos aren't up for so= me reason....=C2=A0 It was very
eye-opening doing this work...

Warner
--0000000000001a7b71060e029e2b--