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

[Mark Kettenis]

> From: Alexander Graf <agraf at suse.de>
> Date: Fri, 15 Jun 2018 15:12:31 +0200
> 
> 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?

Unfortunately not.  On hardware with security extensions, but without
virtualization extensions, we'll start out in secure SVC before
running the first EFI payload and in non-secure SVC afterwards.

> > 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 :)

Indeed.