[PATCH v2 1/1] efi_loader: architecture specific UEFI setup

Fri Feb 14 13:37:21 CET 2020


> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Friday, February 14, 2020 8:07 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>
> Cc: Alexander Graf <agraf at csgraf.de>; Atish Patra <atishp at atishpatra.org>;
> Heinrich Schuchardt <xypron.glpk at gmx.de>; U-Boot Mailing List <u-
> boot at lists.denx.de>; Atish Patra <Atish.Patra at wdc.com>;
> leif at nuviainc.com
> Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI setup
> 
> On Fri, 14 Feb 2020 at 13:04, Chang, Abner (HPS SW/FW Technologist)
> <abner.chang at hpe.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> > > Sent: Friday, February 14, 2020 7:33 PM
> > > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>
> > > Cc: Alexander Graf <agraf at csgraf.de>; Atish Patra
> > > <atishp at atishpatra.org>; Heinrich Schuchardt <xypron.glpk at gmx.de>;
> > > U-Boot Mailing List <u- boot at lists.denx.de>; Atish Patra
> > > <Atish.Patra at wdc.com>; leif at nuviainc.com
> > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific UEFI
> > > setup
> > >
> > > On Fri, 14 Feb 2020 at 12:27, Chang, Abner (HPS SW/FW Technologist)
> > > <abner.chang at hpe.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Alexander Graf [mailto:agraf at csgraf.de]
> > > > > Sent: Friday, February 14, 2020 4:07 PM
> > > > > To: Chang, Abner (HPS SW/FW Technologist)
> <abner.chang at hpe.com>
> > > > > Cc: Atish Patra <atishp at atishpatra.org>; Ard Biesheuvel
> > > > > <ard.biesheuvel at linaro.org>; Heinrich Schuchardt
> > > > > <xypron.glpk at gmx.de>; U-Boot Mailing List
> > > > > <u-boot at lists.denx.de>; Atish Patra <Atish.Patra at wdc.com>;
> > > > > leif at nuviainc.com
> > > > > Subject: Re: [PATCH v2 1/1] efi_loader: architecture specific
> > > > > UEFI setup
> > > > >
> > > > >
> > > > >
> > > > > > Am 14.02.2020 um 05:21 schrieb Chang, Abner (HPS SW/FW
> > > > > > Technologist)
> > > > > <abner.chang at hpe.com>:
> > > > > >
> > >
> > > ...
> > > > > The table  from this link https://github.com/riscv/riscv-
> > > > > smbios/blob/master/RISCV-SMBIOS.md
> > > > > > Offset 3 is HART ID, and offset 13h is the boolean indicates
> > > > > > this hart is the
> > > > > boot hart.
> > > > > >
> > > > > >> kernel. How difficult is to modify the DT in EDK2 ?
> > > > > >>
> > > > > > I never used DT before on PC/Server project. However, the DT
> > > > > > code is over
> > > > > there in edk2 repo which mostly used by ARM platforms. I don’t
> > > > > think it is difficult to adopt it though.
> > > > >
> > > > > Yes, some arm platforms already transform the DT just fine.
> > > > > Let's really please not use SMBIOS for anything boot or system
> > > > > configuration related: its purpose is in general purely informational.
> > > > As DT to embedded system, SMBIOS provides system
> > > information/configuration on most PC/Server platforms. Especially to
> > > pre-OS applications such as EFI diagnostic tool, factory/customer
> > > deployment tools, pre-OS system configuration, network boot image
> > > and EFI OS  boot loader as well. The intention of RISC-V SMBIOS is
> > > support above applications using single image for the RISC-V core
> > > variants, Non ACPI-aware OS is also part of this scope, but it is rare
> though.
> > > > If you are booting to OS which is actually well understand DT then
> > > > just use
> > > DT, but for PC/Server industry, SMBIOS would be still our choice before
> OS.
> > > > We may have to define the corresponding syntax If DT doesn't have
> > > > it for
> > > boot HART information. RISC-V System Description Task Group (f it
> > > formed) would be a good place to bring this topic.
> > > > Maybe you can support both DT or SMBIOS to retrieve the
> > > > information you
> > > need on demand...
> > > >
> > >
> > > SMBIOS is an informational protocol. Firmware or OS loaders should
> > > not rely on it for low-level things like the hart id.
> > Hart ID is just one of the information in type 44 which is the same as the
> processor information provided in type 4.
> >
> 
> Fine. But that doesn't mean we should be parsing SMBIOS tables in the Linux
> startup code.
Ok, this is not my familiar area. You guys are better than me.

> 
> > >
> > > > >
> > > > > So yes, unless I hear really good arguments against passing it
> > > > > via /chosen in DT, I'd strongly prefer that mechanism. For ACPI
> > > > > (if it ever happens), there would be a special ACPI table for it anyway.
> > > > Yes, we do have an ECR for ACPI spec to report the RISC-V core
> > > characteristic which is similar to what we done for SMBIOS.
> > > >
> > >
> > > So we'll end up with a DT+SMBIOS or ACPI+SMBIOS boot protocol, and
> > > we'll always have to parse two sets of tables, just to discover the
> > > hart id. I don't think that makes sense at all, to be honest.
> > As I said, SMBIOS is mostly for pre OS applications, Type 42 is a good
> example, the Host interface used to talk to BMC and Redfish service in pre-
> OS environment (also runtime OS).
> > For OS boot, maybe OS (like Windows) still retrieves information from it
> before ACPI enable.
> >
> > I have no preference of using which way to get boot hard ID for the
> > boot process, either to get it from DT, SMBIOS or  ACPI seems to me
> > the same... just the information is provided over there
> >
> > >
> > > SMBIOS is wonderful for the sysadmin to look at the model numbers of
> > > the installed DIMMs etc. But for core boot stuff, we really should avoid it.
> > Security consideration?
> 
> What security considerations did you have in mind?
Hah this is my question for you. Can someone under Pre-OS environment and steal boot hard ID and do something bad? Or change it to run malicious code from another HART?