Re: [PATCH v2 0/7] Add LoadFile2 and riscv Linux loader

[Ard Biesheuvel]

On Tue, 29 Jun 2021 at 21:13, Atish Patra <atishp@atishpatra.org> wrote:
>
> On Mon, Jun 28, 2021 at 2:24 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 
> wrote:
> >
> >
> > +cc Ard Biesheuvel <ardb@kernel.org>
> >
> > Ard, please see question for you below.
> >
> > On 6/27/21 11:01 PM, Heinrich Schuchardt wrote:
> > > On 6/26/21 8:07 PM, Andreas Schwab wrote:
> > >> On Jun 03 2021, Nikita Ermakov wrote:
> > >>
> > >>> This series contains patches to add support for LoadFile2 protocol to
> > >>> load
> > >>> initrd on EFI systems. Also it contains patches to load Linux kernel
> > >>> with EFI
> > >>> stub on riscv platforms and unites arm and riscv codes together into
> > >>> common
> > >>> loader code for EFI systems.
> > >>
> > >> That doesn't work with a CD image.  When I try to run
> > >> http://download.opensuse.org/ports/riscv/tumbleweed/iso/openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > >>
> > >> with qemu, the initrd fails to load.
> > >
> > > Please, indicate how you built u-boot.bin.
> > >
> > >>
> > >> $ qemu-system-riscv64 -M virt -nographic -serial mon:stdio -smp 4 -m
> > >> 8g -kernel u-boot.bin -drive
> > >> format=raw,if=virtio,media=cdrom,file=openSUSE-Tumbleweed-NET-riscv64-Media.iso
> > >>
> > >
> > > This command results in an error
> > >
> > > qemu-system-riscv64: warning:
> > > No -bios option specified. Not loading a firmware.
> > >
> > > Please, provide a repo with the GRUB code you have been compiling.
> > >
> > >>
> > >> OpenSBI v0.9
> > >>     ____                    _____ ____ _____
> > >>    / __ \                  / ____|  _ \_   _|
> > >>   | |  | |_ __   ___ _ __ | (___ | |_) || |
> > >>   | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > >>   | |__| | |_) |  __/ | | |____) | |_) || |_
> > >>    \____/| .__/ \___|_| |_|_____/|____/_____|
> > >>          | |
> > >>          |_|
> > >>
> > >> Platform Name             : riscv-virtio,qemu
> > >> Platform Features         : timer,mfdeleg
> > >> Platform HART Count       : 4
> > >> Firmware Base             : 0x80000000
> > >> Firmware Size             : 124 KB
> > >> Runtime SBI Version       : 0.2
> > >>
> > >> Domain0 Name              : root
> > >> Domain0 Boot HART         : 1
> > >> Domain0 HARTs             : 0*,1*,2*,3*
> > >> Domain0 Region00          : 0x0000000080000000-0x000000008001ffff ()
> > >> Domain0 Region01          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
> > >> Domain0 Next Address      : 0x0000000080200000
> > >> Domain0 Next Arg1         : 0x00000000bf000000
> > >> Domain0 Next Mode         : S-mode
> > >> Domain0 SysReset          : yes
> > >>
> > >> Boot HART ID              : 1
> > >> Boot HART Domain          : root
> > >> Boot HART ISA             : rv64imafdcsu
> > >> Boot HART Features        : scounteren,mcounteren,time
> > >> Boot HART PMP Count       : 16
> > >> Boot HART PMP Granularity : 4
> > >> Boot HART PMP Address Bits: 54
> > >> Boot HART MHPM Count      : 0
> > >> Boot HART MHPM Count      : 0
> > >> Boot HART MIDELEG         : 0x0000000000000222
> > >> Boot HART MEDELEG         : 0x000000000000b109
> > >>
> > >>
> > >> U-Boot 2021.04 (Jun 09 2021 - 00:00:00 +0000)
> > >>
> > >> CPU:   rv64imafdcsu
> > >> Model: riscv-virtio,qemu
> > >> DRAM:  8 GiB
> > >> In:    uart@10000000
> > >> Out:   uart@10000000
> > >> Err:   uart@10000000
> > >> Net:   No ethernet found.
> > >> Hit any key to stop autoboot:  0
> > >>
> > >> Device 0: 1af4 VirtIO Block Device
> > >>              Type: Hard Disk
> > >>              Capacity: 225.7 MB = 0.2 GB (462376 x 512)
> > >> ... is now current device
> > >> ** Invalid partition 3 **
> > >> ** Invalid partition 4 **
> > >> ** Invalid partition 2 **
> > >> Scanning virtio 0:1...
> > >> ** Unable to read file / **
> > >> Failed to load '/'
> > >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > >> Scanning disk virtio-blk#8...
> > >> Found 2 disks
> > >> No EFI system partition
> > >> BootOrder not defined
> > >> EFI boot manager: Cannot load any image
> > >> Found EFI removable media binary efi/boot/bootriscv64.efi
> > >
> > > When I press 'e' in GRUB I see:
> > >
> > > setparams 'Installation'
> > > set gfxpayload=keep
> > > echo 'Loading kernel ...'
> > > linux /boot/riscv64/linux splash=silent
> > >                                                        echo 'Loading
> > > initial ramdisk ...'                                         initrd
> > > /boot/riscv64/initrd
> > >
> > > With debug=all I get as output:
> > >
> > > kern/verifiers.c:88: file: /boot/riscv64/initrd type: 131076
> > > loader/efi/linux.c:368: LoadFile2 initrd loading protocol installed
> > >
> > > With a bit of debugging enabled in U-Boot:
> > >
> > >        EFI: Call: image_obj->entry(image_handle, &systab)
> > >          EFI: Entry efi_open_protocol(00000000ff751310,
> > > EFI_LOADED_IMAGE_PROTOCOL_GUID, 00000000ff73a6e0, 00000000ff750050,
> > > 0000000000000000, 0x1)
> > >          EFI: Exit: efi_open_protocol: 0
> > > EFI stub: Booting Linux Kernel...
> > >          EFI: Entry efi_locate_handle_ext(2,
> > > EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID, 0000000000000000, 00000000ff73a740,
> > > 0000000000000000)
> > >          EFI: Exit: efi_locate_handle_ext: 14
> > >          EFI: Entry efi_locate_protocol(EFI_TPM2_GUID, 0000000000000000,
> > > 00000000ff73a648)
> > >          EFI: Exit: efi_locate_protocol: 14
> > > EFI stub: Using DTB from configuration table
> > >          EFI: Entry efi_locate_device_path(EFI_LOAD_FILE2_PROTOCOL_GUID,
> > > 00000000ff73a648, 00000000ff73a668)
> > >            EFI: Call: efi_locate_handle_buffer(BY_PROTOCOL, protocol,
> > > NULL, &no_handles, &handles)
> > >              EFI: Entry efi_locate_handle_buffer(2,
> > > EFI_LOAD_FILE2_PROTOCOL_GUID, 0000000000000000, 00000000ff73a5d8,
> > > 00000000ff73a5d0)
> > >              EFI: Exit: efi_locate_handle_buffer: 0
> > >            EFI: 0 returned by efi_locate_handle_buffer(BY_PROTOCOL,
> > > protocol, NULL, &no_handles, &handles)
> > >          EFI: Exit: efi_locate_device_path: 0
> > >          EFI: Entry efi_open_protocol(00000000ff74c8b0,
> > > EFI_LOAD_FILE2_PROTOCOL_GUID, 00000000ff73a650, 00000000ff750050,
> > > 0000000000000000, 0x1)
> > >          EFI: Exit: efi_open_protocol: 0
> > >          EFI: Exit: efi_open_protocol: 0
> > >          EFI: Entry efi_allocate_pages_ext(AllocateMaxAddress,
> > > EfiLoaderData, 0xc024, 00000000ff73a618)
> > >          EFI: Exit: efi_allocate_pages_ext: 9 (EFI_OUT_OF_RESOURCES)
> > >
> > > EFI stub: ERROR: Failed to load initrd!
> > >
> > > The LOAD_FILE2 protocol was successfully opened on the handle ff74c8b0
> > > where it was installed by GRUB.
> > >
> > > *Allocating memory for the initrd fails.*
> > >
> > > 0xC024 pages are requested below 0x901fffff.
> > >
> > > This is the memory map when the call is executed:
> > >
> > > Type             Start            End              Attributes
> > > ================ ================ ================ ==========
> > > BOOT DATA        0000000100000000-0000000280000000 WB
> > > LOADER DATA      00000000fff62000-0000000100000000 WB
> > > RUNTIME CODE     00000000fff61000-00000000fff62000 WB|RT
> > > LOADER DATA      00000000fe73f000-00000000fff61000 WB
> > > BOOT DATA        00000000fe73d000-00000000fe73f000 WB
> > > RESERVED         00000000fe73c000-00000000fe73d000 WB
> > > BOOT DATA        00000000fe73a000-00000000fe73c000 WB
> > > RESERVED         00000000fe739000-00000000fe73a000 WB
> > > RUNTIME DATA     00000000fe735000-00000000fe739000 WB|RT
> > > BOOT DATA        00000000fe734000-00000000fe735000 WB
> > > RUNTIME DATA     00000000fe730000-00000000fe734000 WB|RT
> > > BOOT DATA        00000000fe72f000-00000000fe730000 WB
> > > RESERVED         00000000fe728000-00000000fe72f000 WB
> > > LOADER CODE      00000000fe4aa000-00000000fe728000 WB
> > > LOADER DATA      00000000fe4a9000-00000000fe4aa000 WB
> > > BOOT DATA        00000000fe4a8000-00000000fe4a9000 WB
> > > RESERVED         00000000fe4a6000-00000000fe4a8000 WB
> > > LOADER DATA      00000000fe4a3000-00000000fe4a6000 WB
> > > LOADER CODE      00000000deb8d000-00000000fe4a3000 WB
> > > LOADER DATA      00000000dd620000-00000000deb8d000 WB
> > > LOADER CODE      00000000dbfc3000-00000000dd620000 WB
> > > BOOT DATA        00000000dbfc2000-00000000dbfc3000 WB
> > > CONVENTIONAL     0000000087f05000-00000000dbfc2000 WB
> > > ACPI RECLAIM MEM 0000000087efb000-0000000087f05000 WB
> > > CONVENTIONAL     000000008185d000-0000000087efb000 WB
> > > LOADER DATA      0000000080200000-000000008185d000 WB
> > > CONVENTIONAL     0000000080040000-0000000080200000 WB
> > > BOOT DATA        0000000080000000-0000000080040000 WB
> > >
> > > 0x901fffff - 0x1000 * 0xC024 = 0x841DBFFF
> > >
> > > So U-Boot is correct in indicating that the memory is not available at
> > > the required low address.
> > >
> > > In Linux efi_load_initrd() is called with parameter hard_limit being the
> > > 'minimum size of allocated memory'. But this parameter is passed to
>
> The function comment header should be updated to reflect the correct usage. 
> No ?
>

Agreed. The allocation limits are physical upper bounds, not sizes.

> > > efi_load_initrd_dev_path() as 'upper limit for the initrd memory
> > > allocation' and further to efi_allocate_pages() as 'the address that the
> > > last allocated memory page shall not exceed'.
> > >
> > > @Ard
> > > Why does Linux require allocating the memory below 0x901fffff which is
> > > the value of 'minimum size of allocated memory'? I think initrd can be
> > > allocated anywhere in memory even above 4GiB.
> > >
>
> That should be fine. I think this bug was present during initial
> porting but never got exposed because I never used
> such a big initrd. Thanks for providing the fix.
>

I don't know about RISC-V in particular, but in general, there are
limits to where the initrd can be loaded, depending on how the
architecture organizes its linear mapping of DRAM. If no such
limitation exists for RISC-V, the code should be updated accordingly.