Am April 27, 2020 7:39:38 PM UTC schrieb Ard Biesheuvel <a...@kernel.org>:
>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.
Will GRUB provide the absolute device path in parameter file_path?
>
>> 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
