[External] Re: [PATCH v3 0/4] Obtain SMBIOS and ACPI entry from FFI

Fri Jul 7 01:38:30 PDT 2023

Hey,

I've tried to reformat this a bit, probably gone wrong in the process
somewhere.

On Thu, Jul 06, 2023 at 02:39:13PM -0700, ron minnich wrote:
> On Thu, Jul 6, 2023 at 8:32 AM Palmer Dabbelt <palmer at dabbelt.com<mailto:palmer at dabbelt.com>> wrote:
> > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote:
> > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui at bytedance.com<mailto:cuiyunhui at bytedance.com>> wrote:
> > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt <palmer at dabbelt.com<mailto:palmer at dabbelt.com>> wrote:
> > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), cuiyunhui at bytedance.com<mailto:cuiyunhui at bytedance.com> wrote:
> > >> > > Here's version 3 of patch series.
> > >> > >
> > >> > > V1: The FFI (FDT FIRMWARE INTERFACE) scheme has reached a
> > >> > > consensus with the Maintainers.
> > >> > > Please refer to:
> > >> > > https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@bytedance.com/
> > >> >
> > >> > From looking at that thread it seems that the consensus is this is a bad
> > >> > idea?  Sorry if I'm just missing something...
> > >> >
> > >>
> > >> First of all, Coreboot does not support EFI, Ron has expressed, as follows:
> > >> "I am wondering if we can focus on risc-v here, and not drag in ARM,
> > >> b/c the ARM ACPI+UEFI ship has sailed. I had that discussion in 2013
> > >> ;-) and it's clear we don't want to redo it.
> > >> In general, in my world, because of the many problems that come with
> > >> UEFI (security, code quality, performance), we'd like to avoid
> > >> requiring a dependency on UEFI just to get ACPI on RISC-V. It also
> > >> seems, from other discussions I'm having, that there is some belief
> > >> that ACPI will be wanted on RISC-V. It would be nice to separate those
> > >> pieces on RISC-V; certainly they were separate for a very long time in
> > >> the x86 world (we had ACPI+SMM on coreboot laptops without UEFI for
> > >> example)."
> > >>
> > >
> > > There appears to be a bit of cargo cult going on here.
> > >
> > > I agree that the traditional BIOS vendors did a terrible job pivoting
> > > to (U)EFI when it became a requirement for booting Windows on x86 PCs,
> > > and coreboot did an excellent job providing a retrofit alternative
> > > that was more secure and robust.
> > >
> > > However, it makes sense to distinguish between
> > > a) the UEFI specification
> > > b) the UEFI reference implementation (edk2)
> > > c) commercial implementations created by BIOS vendors for x86 PC OEMs
> > > that do not perform any testing beyond booting Windows.
> > >
> > > coreboot decided not to implement EFI at all, which on x86 means
> > > booting in a mode that is similar to BIOS boot. Given how the ACPI and
> > > DMTF (for SMBIOS) specifications were already under development when
> > > UEFI was being rolled out on x86, those specs contain provisions
> > > defining how to obtain the ACPI and SMBIOS tables by scanning regions
> > > of memory and looking for magic strings. But this is only defined for
> > 
> > In theory we have that in RISC-V as well: on boot we don't actually have
> > a DT pointer, but instead a "config string" pointer.  That's a bit of a
> > retcon from when we were planning on adding our own firmware probing
> > interface, but in order to appear to have never made a mistake we just
> > said that config strings can be anything and have magic numbers to
> > differentiate between the flavors.
> > 
> > IIUC we don't take advantage of that in Linux, though, so maybe let's
> > just pretend it doesn't exist?
> > 
> > > x86, and only works on x86 because all x86 machines are essentially
> > > PCs with a highly uniform system topology.
> > >
> > > The ARM case is very different, and while I am no expect on RISC-V,
> > > the following probably applies to it as well:
> > > - there is no need to work around buggy proprietary firmware that can
> > > boot Windows but not Linux
> > > - there is no 'prior art' when it comes to pre-EFI boot interfaces
> > > except for embedded style bare metal boot where all initialization is
> > > done by the kernel (e.g., PCI enumeration and resource assignment
> > > etc), and this is fundamentally arch specific
> > > - ACPI is a rich firmware interface, and the ACPI specification layers
> > > it on top of UEFI so the OS can make certain assumptions about the
> > > extent to which the platform has been initialized by the time it hands
> > > over.
> > >
> > > This is why the maintainers of the arm64 and RISC-V ports appear to
> > > agree that ACPI will only be supported when booting from firmware that
> > 
> > Yes, we're basically in the same spot as arm64 is here -- or at least
> > we're aiming to be, we've yet to even release a kernel that boots with
> > ACPI so we have no legacy compatibility yet.
> > 
> > > implements the EFI specification. Note that this does not impose any
> > > requirement at all regarding which EFI implementation is going to be
> > > used: suggestions have been made on the thread to use a) a coreboot
> > > specific minimal EFI shim that describes the firmware tables and the
> > > EFI memory map, b) the UPL payload for coreboot, and c) U-Boot's EFI
> > > implementation.
> > >
> > > I will also note that booting according to the EFI spec is not
> > > fundamentally  more secure or faster: I have done some experiments on
> > > arm64 comparing bare metal boot with EFI boot using a minimal
> > > implementation in Rust, for booting virtual machines under KVM. Due to
> > > cache maintenance overhead and execution with the MMU disabled, bare
> > > metal boot is actually slightly slower. And due to the fact that the
> > > minimal EFI firmware enables the MMU and caches straight out of reset,
> > > it is also arguably more secure, given that all memory permission
> > > based protections and other page table based hardening measures (e.g.,
> > > BTI) are always enabled.
> > >
> > > In summary, I think it may be time to stop extrapolating from bad
> > > experiences with buggy proprietary x86 PC firmware created by
> > > traditional BIOS vendors for booting Windows (and nothing else) 15+
> > > years ago. The situation is very different for non-x86 Linux
> > > architectures, where we are trying hard to beat some sense into the
> > > fragmented embedded ecosystem, where every SoC vendor used to have its
> > > own fork of u-boot that booted in a slightly different manner,
> > > requiring a lot of effort on the part of the distros to track all
> > > those moving targets.
> > 
> > That's roughly where we're trying to go in RISC-V land, at least for
> > most software people.  Everyone gets their own ISA, which obviously
> > causes a ton of fragmentation, but not really anything we can do about
> > that.  At least we can avoid adding additional sources of fragmentation
> > from the software side of things, though.
> > 
> > >> Then, a consensus was reached with Ard, that FFI can be applied to RISC-V.
> > >>
> > >
> > > For the record, I would not characterize this as consensus. What I said was
> > > - SMBIOS has very little significance to the kernel itself or impact
> > > on its internal operation, and so it can be exposed via DT in a
> > > generic manner;
> > > - ACPI without UEFI on non-x86 is a) a bad idea, and b) fundamentally
> > > broken on arm64. So b) is out of the question, but it is not up to me
> > > to decide whether or not the RISC-V maintainers should entertain bad
> > > ideas.
> > 
> > IMO we have enough bad ideas in RISC-V already and thus should avoid
> > adding more.

> ACPI was not originally part of UEFI. ACPI works just fine on
> Chromebooks, and has for 12 years, and on coreboot since 2006,
> without UEFI. I've integrated support for ACPI into several
> code bases, including Plan 9 on non-UEFI systems.
> 
> I am unable to understand the claim that ACPI on non-UEFI
> RISC-V is a bad idea. Clearly, I am not alone.
> 
> But, all that said, I get the impression that the gatekeepers
> are absolutely immovable on this question?

> Perhaps the right way
> to move forward is to find a way to extract what we need from ACPI
> and move forward on systems that can function without UEFI AND ACPI?
> Would that be preferable?

Isn't this exactly the type of thing that has been proposed by this
series, that everyone seems to be against? Or are you suggesting that we
would, on a DT system, read some ACPI information, and then revert to
being DT based?

> Just so we're all on the same page, I just now asked Mark Himelstein
> of RISC-V International if there is anything in RISC-V standards that
> requires UEFI, and the answer is a solid "no."

Huh? Firstly, running off to invoke RVI is not productive - they don't
maintain the various operating system kernels etc.
Secondly, that does not seem to be true. The platform spec mandates UEFI
for the OS-A server platform, alongside ACPI:
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process
and the OS-A embedded platform needs to comply with EBBR & use DT:
https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process

EBBR does say that systems must not provide both ACPI and DT to the OS
loader, but I am far from an expert on these kind of things & am not
sure where something like this where the DT "contains" ACPI would stand.

The RISC-V ACPI spec also says "UEFI firmware is mandatory to support
ACPI":
https://github.com/riscv-non-isa/riscv-acpi/blob/master/riscv-acpi-guidance.adoc

Jess, Sunil or Ard on the EBBR front perhaps, please correct me here if I
have got anything wrong.

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230707/5bfe91b0/attachment.sig>