[U-Boot] [PATCH v3 0/3] efi_loader: ARM: add support for ARMV7_NONSEC=y

[Alexander Graf]

Am 15.06.2018 um 15:01 schrieb Mark Kettenis <mark.kettenis at xs4all.nl>:

>> From: Alexander Graf <agraf at suse.de>
>> Date: Fri, 15 Jun 2018 12:49:48 +0200
>> 
>>> On 15.06.18 05:39, Heinrich Schuchardt wrote:
>>> On 06/14/2018 10:50 PM, Mark Kettenis wrote:
>>>>> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>> Date: Thu, 14 Jun 2018 19:55:51 +0200
>>>>> 
>>>>>> On 06/14/2018 12:41 AM, Mark Kettenis wrote:
>>>>>> This series makes it possible to run EFI applications in non-secure
>>>>>> mode.  It allows me to run OpenBSD on the Technexion PICO-PI-IMX7 and
>>>>>> Banana Pi boards using the PSCI implementation provided by U-Boot.
>>>>>> 
>>>>>> The second version avoids using r3 to pass the original stack pointer.
>>>>>> For some reason that register gets clobbered on the Banana Pi.  Instead
>>>>>> this version just migrates SP_svc to SP_hyp.
>>>>>> 
>>>>>> This third version avoids saving r3 on the stack and fixes an include
>>>>>> guard as suggested by Alexander Graf.
>>>>>> 
>>>>>> Mark Kettenis (3):
>>>>>>  ARM: HYP/non-sec: migrate stack
>>>>>>  efi_loader: ARM: run EFI payloads non-secure
>>>>>>  Revert "efi_loader: no support for ARMV7_NONSEC=y"
>>>>>> 
>>>>>> arch/arm/cpu/armv7/nonsec_virt.S |  2 ++
>>>>>> cmd/bootefi.c                    | 32 ++++++++++++++++++++++++++++++++
>>>>>> doc/README.uefi                  |  2 --
>>>>>> lib/efi_loader/Kconfig           |  2 --
>>>>>> 4 files changed, 34 insertions(+), 4 deletions(-)
>>>>>> 
>>>>> Hello Mark,
>>>>> 
>>>>> with this patch series running bootefi hello twice in sequence fails on
>>>>> the BananaPi.
>>>>> 
>>>>> => bootefi hello
>>>>> Scanning disk mmc at 01c0f000.blk...
>>>>> Found 3 disks
>>>>> WARNING: booting without device tree
>>>>> ## Starting EFI application at 42000000 ...
>>>>> WARNING: using memory device/image path, this may confuse some payloads!
>>>>> Hello, world!
>>>>> Running on UEFI 2.7
>>>>> Have SMBIOS table
>>>>> Load options: earlyprintk nosmp
>>>>> ## Application terminated, r = 0
>>>>> => bootefi hello
>>>>> WARNING: booting without device tree
>>>>> ## Starting EFI application at 42000000 ...
>>>>> WARNING: using memory device/image path, this may confuse some payloads!
>>>>> <!-- no output after the preceding line -->
>>>> 
>>>> Yeah.  Trying to enter non-secure mode when we're already in
>>>> non-secure mode doesn't really work.  We should skip the switching
>>>> code in that case.  Now checking whether we are in non-secure mode
>>>> isn't really possible.  But I guess we can set a variable and check it
>>>> before we go down the switching codepath.  With that in I can exit the
>>>> OpenBSD bootloader and then reload and run it again.  I'll include
>>>> that fix in the next respin.
>>> 
>>> Hello Mark,
>>> 
>>> you might move the call to switch to non-secure mode to efi_init_obj_list().
>> 
>> I would actually prefer to keep it where it is. That way we have the
>> option to move the object initialization to a different stage later on.
> 
> Also I'd rather not touch the aarch64 code in this series and I think
> it makes sense to keep the switching in the same place for aarch32 and
> aarch64.
> 
>> The only thing missing is really a check which level we're on. The
>> aarch64 code does this with a current_el() == 3 condition.
> 
> As I replied to Heinrich, checking whether we're secure or not isn't
> simple as reading the SCR.NS bit will trap if we're in non-secure
> mode.  But using a global variable to remember the state we're in,
> works and isn't too ugly.

Can you figure out something else? Like whether you're in SVC?

> I'm going to look into enabling the MMU for HYP over the weekend.
> I'll do another respin once I've figured that issue out.

It might just be as simple as depending on LPAE in Kconfig when NS is set :)

Alex