Re: [PATCH RFC/RFT 0/3] Add grub loader support for RISC-V Linux

[Heinrich Schuchardt]

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 <address@hidden> 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?

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?

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."

Best regards

Heinrich

>>
>> The resulting code could serve as a legacy-free 'generic' EFI target,
>> that could work on all architectures, including x86, provided that the
>> kernel you are booting is recent enough (and that issue will solve
>> itself over time)
>
> I fully agree with Ard, this is way to go...
>
> Daniel
>