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.kette...@xs4all.nl> wrote:
> > >
> > > > Date: Thu, 14 Dec 2023 15:53:46 +0000
> > > > From: Abdellatif El Khlifi <abdellatif.elkhl...@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 ?
>
> Suggested changes (pseudo-code):
>
> __efi_runtime mm_communicate () {
> #if CONFIG_IS_ENABLED(ARM_FFA_TRANSPORT)
> if (RT) { /* NEW */
> ret = ffa_mm_communicate_runtime(comm_buf, dsize); /* NEW */
> } else {
> mm_comms = get_mm_comms();
> if (mm_comms == MM_COMMS_FFA)
> ret = ffa_mm_communicate(comm_buf, dsize);
> else
> ret = optee_mm_communicate(comm_buf, dsize);
> }
> #else
> ...
> #endif
>
> Existing code:
> https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_variable_tee.c#L417
A gentle reminder about the question above please (Is there a way to check
whether we are in EFI runtime or not).
Cheers,
Abdellatif
