Message-ID: <CAOnJCU+1vOk3AkGPBah8gPzwf1V1PXUfdxq9+Y17P=F_rOp9hg@mail.gmail.com>
Date:   Sat, 3 Oct 2020 10:16:44 -0700
From:   Atish Patra <atishp@...shpatra.org>
To:     Heinrich Schuchardt <xypron.glpk@....de>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub

On Sat, Oct 3, 2020 at 1:29 AM Heinrich Schuchardt <xypron.glpk@....de> wrote:
>
> On 03.10.20 09:34, Atish Patra wrote:
> > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@....de> wrote:
> >>
> >> Describe how a device tree and an initial RAM disk can be passed to the EFI
> >> Boot Stub.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@....de>
> >> ---
> >> v2:
> >>         mention EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER (thx Atish)
> >> ---
> >>  Documentation/admin-guide/efi-stub.rst | 35 ++++++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>
> >> diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst
> >> index 833edb0d0bc4..4965dec48af4 100644
> >> --- a/Documentation/admin-guide/efi-stub.rst
> >> +++ b/Documentation/admin-guide/efi-stub.rst
> >> @@ -38,6 +38,34 @@ arch/arm/boot/zImage should be copied to the system partition, and it
> >>  may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
> >>  should be copied but not necessarily renamed.
> >>
> >> +Passing an initial RAM disk to the EFI Boot Stub
> >> +------------------------------------------------
> >> +
> >> +The following means sorted by decreasing priority can be used to provide an
> >> +initial RAM disk to the EFI Boot Stub:
> >> +
> >> +* The firmware may provide a UEFI Load File 2 Protocol. The stub will try to
> >> +  load the RAM disk by calling the LoadFile() service of the protocol using
> >> +  a vendor device path with the vendor GUID
> >> +  5568e427-0x68fc-4f3d-ac74-ca555231cc68.
> >> +* Next the EFI stub will try to load the file indicated by the "initrd=" command
> >> +  line parameter if CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is enabled.
> >> +* The prior boot stage may pass the location of the initial RAM disk via the
> >> +  "linux,initrd-start" and "linux,initrd-end" properties of the "/chosen" node
> >> +  of the device-tree.
> >> +
> >
> > Should we also specify which method is enabled by default for which
> > ARCH and recommended methods?
>
> The user relevant configuration is not the Linux' defconfig but what the
> distribution maintainer has baked. I doubt mentioning Linux' defaults is
> meaningful here.
>

Yes. But some distribution admin may think that one of these two configs
(initrd or dtb) are not enabled for RISC-V by mistake and enable it in
the distro config.
Ard had suggested that it is best if RISC-V doesn't inherit the legacy options.

> >
> > For example, It's recommended to use the LoadFile method for RISC-V
> > and new ARM systems.
>
> GRUB does not implement the LoadFile2 protocol yet. In U-Boot it is only
> good for testing. I am not aware of usability with unmodified EDK II.
> Why should we recommend anything before building the ecosystem that
> makes it useful?
>
> What is best may depend on the use case. There is nothing insecure in
> passing the initrd via "linux,initrd-start" and "linux,initrd-end" if
> you control the load options.
>
> The EBBR (https://github.com/arm-software/ebbr) might be a better place
> for a recommendation.
>

Agreed.

> > Existing ARM ones will continue to use the initrd argument as that's
> > the method enabled by default.
>
> Only if if the LoadFile2 protocol is not available because that has a
> higher priority for ARM, x86, and RISC-V.
>
> Should I consider my i.mx6 Wandboard Quad bought in 2013 "old" while it
> is running the U-Boot v2020.10-rc5, Linux v5.9-rc7, and Debian testing?
> A distinction between "old" and "new" systems seems irrelevant here. All
> are treated equal by the EFI stub.
>
> >
> >> +The first two items are inhibited by the "noinitrd" command line parameter.
> >> +
> >> +Passing a device-tree to the EFI Boot Stub
> >> +------------------------------------------
> >> +
> >> +A device-tree can be passed to the EFI Boot Stub in decreasing priority using
> >> +
> >> +* command line option dtb=
> >> +* a UEFI configuration table with GUID b1b621d5-f19c-41a5-830b-d9152c69aae0.
> >> +
> >
> > I am just curious. Is there any specific reason why efistub tries to
> > load the dtb from the command line first
> > and loads from the config table only if it fails from the first approach ?
>
> As we disable dtb= in secure boot it would make sense to turn the
> priorities around for non-secure boot too.
>
> But this is beyond the scope of a documentation patch.
>

Yes. I was just using the context to ask the question. I will send a
separate patch
for that.

> Best regards
>
> Heinrich
>
> >
> >> +The command line option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y
> >> +and secure boot is disabled.
> >>
> >>  Passing kernel parameters from the EFI shell
> >>  --------------------------------------------
> >> @@ -46,6 +74,10 @@ Arguments to the kernel can be passed after bzImage.efi, e.g.::
> >>
> >>         fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
> >>
> >> +The "noinitrd" option
> >> +---------------------
> >> +
> >> +The "noinitrd" option stops the EFI stub from loading an initial RAM disk.
> >>
> >>  The "initrd=" option
> >>  --------------------
> >> @@ -98,3 +130,6 @@ CONFIGURATION TABLE.
> >>
> >>  "dtb=" is processed in the same manner as the "initrd=" option that is
> >>  described above.
> >> +
> >> +This option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y and secure
> >> +boot is disabled.
> >> --
> >> 2.28.0
> >>
> >>
> >> _______________________________________________
> >> linux-riscv mailing list
> >> linux-riscv@...ts.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
> >
>


-- 
Regards,
Atish

Powered by blists - more mailing lists