Adding EFI runtime support to the Arm's FF-A bus

[Abdellatif El Khlifi]

Hi Ilias, Heinrich

On Mon, Jan 08, 2024 at 04:35:59PM +0200, Ilias Apalodimas wrote:
> On Mon, 8 Jan 2024 at 16:32, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >
> > On 08.01.24 15:12, Abdellatif El Khlifi wrote:
> > > Happy new year Ilias,
> > >
> > > On Mon, Dec 18, 2023 at 04:59:09PM +0000, Abdellatif El Khlifi wrote:
> > >> Hi Ilias
> > >>
> > >> On Thu, Dec 14, 2023 at 09:47:13PM +0200, Ilias Apalodimas wrote:
> > >>> Hi Mark, Abdellatif
> > >>>
> > >>> On Thu, 14 Dec 2023 at 18:47, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > >>>>
> > >>>>> Date: Thu, 14 Dec 2023 15:53:46 +0000
> > >>>>> From: Abdellatif El Khlifi <abdellatif.elkhlifi at arm.com>
> > >>>>
> > >>>> Hi Abdellatif,
> > >>>>
> > >>>>> Hi guys,
> > >>>>>
> > >>>>> I'd like to ask for advice regarding adding EFI RT support to the Arm's FF-A bus
> > >>>>> in U-Boot.
> > >>>>>
> > >>>>> The objective is to enable the FF-A messaging APIs in EFI RT to be
> > >>>>> used for comms with the secure world. This will help getting/setting
> > >>>>> EFI variables through FF-A.
> > >>>>>
> > >>>>> The existing FF-A APIs in U-Boot call the DM APIs (which are not available at RT).
> > >>>>>
> > >>>>> Two possible solutions:
> > >>>>>
> > >>>>> 1/ having the entire U-Boot in RT space (as Simon stated in this discussion[1])
> > >>>>
> > >>>> I don't think this is a terribly good idea.  With this approach orders
> > >>>> of magnitude more code will be present in kernel address space one the
> > >>>> OS kernel is running and calling into the EFI runtime.  Including code
> > >>>> that may access hardware devices that are now under OS control.  It
> > >>>> will be nigh impossible to audit all that code and make sure that only
> > >>>> a safe subset of it gets called.  So...
> > >>>
> > >>> +100
> > >>> I think we should draw a line here. I mentioned it on another thread,
> > >>> but I did a shot BoF in Plumbers discussing issues like this,
> > >>> problems, and potential solutions [0] [1]. Since that talk patches for
> > >>> the kernel that 'solve' the problem for RPMBs got pulled into
> > >>> linux-next [2].
> > >>
> > >> I watched your talk. Great work, thanks :)
> > >>
> > >>> The TL;DR of that talk is that if the kernel ends up being in control
> > >>> of the hardware that stores the EFI variables, we need to find elegant
> > >>> ways to teach the kernel how to store those directly. The EFI
> > >>> requirement of an isolated flash is something that mostly came from
> > >>> the x86 world and is not a reality on the majority of embedded boards.
> > >>> I also think we should give up on Authenticated EFI variables in that
> > >>> case. We get zero guarantees unless the medium has similar properties
> > >>> to an RPMB.
> > >>> If a vendor cares about proper UEFI secure boot he can implement
> > >>> proper hardware.
> > >>>
> > >>>>
> > >>>>>
> > >>>>> 2/ Create an RT variant for the FF-A APIs needed.
> > >>>>>        These RT variant don't call the DM APIs
> > >>>>>        (e.g: ffa_mm_communicate_runtime, ffa_sync_send_receive_runtime, ...)
> > >>>>>
> > >>>>> What do you recommend please ?
> > >>>>
> > >>>> ...this is what I would recommend.  Preferably in a way that refactors
> > >>>> the code such that the low-level functionality is shared between the
> > >>>> DM and non-DM APIs.
> > >>>
> > >>> Yes. The only thing you need to keep alive is the machinery to talk to
> > >>> the secure world. The bus, flash driver etc should all be running
> > >>> isolated in there. In that case you can implement SetVariableRT as
> > >>> described the the EFI spec.
> > >>
> > >> Cool, thanks. That's my preferred solution too.
> > >>
> > >> mm_communicate() should be able to detect runtime mode so it calls ffa_mm_communicate_runtime().
> > >>
> > >> Is there a way to check whether we are in EFI runtime or not ?
> >
> > Relevant UEFI event groups for the transition to the OS are:
> >
> > EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES
> > EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
> > EFI_EVENT_GROUP_VIRTUAL_ADDRESS_CHANGE
> >
> > Once EFI_EVENT_GROUP_EXIT_BOOT_SERVICES is signaled you are at runtime.
> >
> > Use CreateEventEx() to create an event for the group.

Thanks

> 
> On top of that, we are already calling
> efi_variables_boot_exit_notify() based on those events. We could reuse
> that
> 

Currently efi_variables_boot_exit_notify() isn't located in the EFI section (__efi_runtime) as shown here [1].

Should we add __efi_runtime to the prototype ?

[1]: https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_variable_tee.c#L945

Cheers,
Abdellatif