[U-Boot] [PATCH v3 2/3] efi_loader: ARM: run EFI payloads non-secure

Sun Sep 23 03:38:29 UTC 2018

On 09/23/2018 04:39 AM, Jonathan Gray wrote:
> On Sun, Sep 23, 2018 at 01:30:11AM +0200, Heinrich Schuchardt wrote:
>> On 09/01/2018 12:21 PM, Alexander Graf wrote:
>>>
>>>
>>> On 31.08.18 20:45, Mark Kettenis wrote:
>>>>> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>> Date: Fri, 31 Aug 2018 19:37:25 +0200
>>>>>
>>>>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>>>>>> If desired (and possible) switch into HYP mode or non-secure SVC mode
>>>>>> before calling the entry point of an EFI application.  This allows
>>>>>> U-Boot to provide a usable PSCI implementation and makes it possible
>>>>>> to boot kernels into hypervisor mode using an EFI bootloader.
>>>>>>
>>>>>> Based on diffs from Heinrich Schuchardt and Alexander Graf.
>>>>>>
>>>>>> Signed-off-by: Mark Kettenis <kettenis at openbsd.org>
>>>>>
>>>>> bootefi hello fails on vexpress_ca15_tc2_defconfig when run on qemu with
>>>>>
>>>>>         QEMU_AUDIO_DRV=none qemu-system-arm \
>>>>>         -M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
>>>>>         -net user -net nic,model=lan9118 \
>>>>>         -m 1024M --nographic \
>>>>>         -drive if=sd,file=img.vexpress,media=disk,format=raw
>>>>
>>>> Works for me with:
>>>>
>>>> $ qemu-system-arm --version
>>>> QEMU emulator version 3.0.0
>>>> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
>>>>
>>>> => bootefi hello
>>>> Scanning disks on mmc...
>>>> MMC Device 1 not found
>>>> MMC Device 2 not found
>>>> MMC Device 3 not found
>>>> Found 3 disks
>>>> WARNING: booting without device tree
>>>> ## Starting EFI application at a0008000 ...
>>>> WARNING: using memory device/image path, this may confuse some payloads!
>>>> Hello, world!
>>>> Running on UEFI 2.7
>>>> Have SMBIOS table
>>>> Load options: <none>
>>>> ## Application terminated, r = 0
>>>>
>>>> That is with CONFIG_CMD_BOOTEFI_HELLO=y added to the
>>>> vexpress_ca15_tc2_defconfig of course.
>>>>
>>>>> Bisection points to
>>>>> efi_loader: ARM: run EFI payloads non-secure
>>>>> commit dc500c369486fbe04000fd325c46bb309e4a1827
>>>>
>>>> That suggests an issue with emulation if the mode switching
>>>> instructions or HYP support in qemu.  Or a toolchain issue of course.
>>>
>>> Or maybe Heinrich's QEMU version starts up in a different EL mode?
>>>
>>>
>>> Alex
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> https://lists.denx.de/listinfo/u-boot
>>>
>> The problem is reproducible with qemu 3.0.0.
>>
>> git reset --hard dc500c369486fbe04000fd325c46bb309e4a1827
>>
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -2,7 +2,6 @@ config EFI_LOADER
>>         bool "Support running EFI Applications in U-Boot"
>>         depends on (ARM || X86 || RISCV) && OF_LIBFDT
>>         # We do not support bootefi booting ARMv7 in non-secure mode
>> -       depends on !ARMV7_NONSEC
>>         # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
>>         depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
>>         # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
>>
>> make vexpress_ca15_tc2_defconfig
>>
>> Set CONFIG_CMD_BOOTEFI_HELLO=y
>>
>> export CROSS_COMPILE=arm-linux-gnueabihf-
>> make
>>
>> QEMU_AUDIO_DRV=none qemu-system-arm \
>> -M vexpress-a15 -cpu cortex-a15 -kernel u-boot \
>> -netdev \
>> user,id=net0,tftp=tftp,net=192.168.76.0/24,dhcpstart=192.168.76.9 \
>> -net nic,model=lan9118,netdev=net0 \
>> -m 1024M --nographic \
>> -drive if=sd,file=img.vexpress,media=disk,format=raw
>>
>> => bootefi hello
>> Scanning disks on mmc...
>> MMC Device 1 not found
>> MMC Device 2 not found
>> MMC Device 3 not found
>> Found 2 disks
>> WARNING: booting without device tree
>> ## Starting EFI application at a0008000 ...
>> WARNING: using memory device/image path, this may confuse some payloads!
>>
>> No further output after this line :(
> 
> bootefi hello works fine with 2018.09 and qemu 3.0 here
> 
> gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- vexpress_ca15_tc2_defconfig O=build/vexpress
> gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- O=build/vexpress menuconfig
> gmake PYTHON=python2.7 CROSS_COMPILE=arm-none-eabi- O=build/vexpress all
> 
> $ arm-none-eabi-gcc -v
> Using built-in specs.
> COLLECT_GCC=arm-none-eabi-gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/arm-none-eabi/6.3.1/lto-wrapper
> Target: arm-none-eabi
> Configured with: /usr/obj/ports/arm-none-eabi-gcc-linaro-6.3.2017.02-arm/gcc-linaro-6.3-2017.02/configure --enable-languages=c,c++ --enable-multilib --enable-interwork --with-gmp=/usr/local --with-newlib --disable-lto --enable-cpp --target=arm-none-eabi --disable-shared --disable-nls --disable-werror --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var --disable-silent-rules --disable-gtk-doc
> Thread model: single
> gcc version 6.3.1 20170109 (Linaro GCC 6.3-2017.02)
> 
> $ qemu-system-arm --version
> QEMU emulator version 3.0.0
> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
> 
> qemu-system-arm -m 1024 -M vexpress-a15 -kernel build/vexpress/u-boot -serial stdio
> 
> U-Boot 2018.09-00001-g2a9fbd55c3 (Sep 23 2018 - 12:24:33 +1000)
> 
> DRAM:  1 GiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC:   MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   smc911x-0
> Hit any key to stop autoboot:  0
> => bootefi hellopi
> Scanning disks on mmc...
> Card did not respond to voltage select!
> MMC Device 1 not found
> MMC Device 2 not found
> MMC Device 3 not found
> Found 0 disks
> WARNING: booting without device tree
> ## Starting EFI application at a0008000 ...
> WARNING: using memory device/image path, this may confuse some payloads!
> Hello, world!
> Running on UEFI 2.7
> Have SMBIOS table
> Load options: <none>
> ## Application terminated, r = 0
> => 
> 
The difference seems to be in the compiler:
With the recipe above arm-none-eabi-gcc 6.3.1 is working but
arm-linux-gnueabihf-gcc 8.2.0 (as supplied with Debian Buster) is still
failing.

Errors like out of bound accesses may become apparent or disappearing
depending of generated addresses. So it may be by chance that we do not
see the error with gcc 6.3.1. This does not imply that the code is correct.

Best regards

Heinrich