On Mon, 27 Apr 2020 at 21:36, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> On 4/27/20 1:01 PM, Daniel Kiper wrote:
> > On Mon, Apr 27, 2020 at 08:15:41AM +0200, Ard Biesheuvel wrote:
> >> On Sun, 26 Apr 2020 at 21:40, Atish Patra <atish.pa...@wdc.com> wrote:
> >>>
> >>> This series adds grub loader support for RISC-V Linux. Thanks to the
> >>> awesome
> >>> initial RISC-V support added by Alex, we just needed a loader for RISC-V
> >>> to
> >>> load and execute Linux using UEFI protocol.
> >>>
> >>> Fortunately, ARM64 Linux loader is written in an architecture agnostic
> >>> manner
> >>> so thatgeneric RISC-V can easily reuse the loader code. Thus, the first
> >>> patch
> >>> just moves the ARM64 code to common code. I have compile tested for
> >>> ARM64/ARM32. Even though it doesn't introduce any functional change
> >>> for ARM/ARM64, any real testing will be helpful.
> >>
> >> May I suggest that we not blindly adopt the ARM code here, but
> >> instead, use the new initrd loading protocol that removes the need for
> >> GRUB to modify or even know about the device tree at all?
>
> Does this protocol exist in EDK2 by now?
>
Yes. It exists as a shell command, and as a load option for OVMF.
> In U-Boot there is a basic implementation which can provide a single
> initrd image with a hardcoded file name. The file_path argument passed
> to U-Boot is ignored due to Ilias' security concerns when he wrote the
> patch.
>
> GRUB is only needed if we have multiple kernels to choose from with
> distinct initial ramdisks.
>
> Please, describe what you expect the initrd loading protocol to do when
> called from GRUB. How will the ramdisk fitting the kernel chosen in GRUB
> be identified?
>
The same what GRUB's 'initrd' command does. Whichever initrd you
select with it is the one that gets returned by the protocol.
> How do you deal with Ilias' security concerns expressed as follows in
> U-boot commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
> initramfs loading"):
>
> "The file location is intentionally only supported as a config option
> argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security.
> Although U-boot is not responsible for verifying the integrity of the
> initramfs, we can enhance the offered security by only accepting a
> built-in option, which will be naturally verified by UEFI Secure Boot."
>
That is an implementation detail of u-boot. This is one way to address
security concerns. Another way might be for U-Boot to check a
signature before it allows a file to be selected as the one to be
returned by the LoadFile2 protocol.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
