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

Wed Dec 20 05:47:59 CET 2023

Hi Heinrich,

On Mon, 18 Dec 2023 at 13:59, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 18. Dezember 2023 16:01:44 MEZ schrieb Simon Glass <sjg at chromium.org>:
> >Hi,
> >
> >On Thu, 14 Dec 2023 at 12:47, Ilias Apalodimas
> ><ilias.apalodimas at linaro.org> 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].
> >> 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.
> >
> >Just to copy in my thoughts as they are lost at this point:
> >
> >> We would need to publish a runtime interface with access to the driver
> >> API. I did ask for this when the EFI runtime support was added, but it
> >> wasn't done.
> >
> >> It would be possible to create a new 'runtime' phase of U-Boot (RPL?),
> >> separate from the others. That will be much easier once we get the XPL
> >> stuff sorted out., since adding new [hase would be fairly trivial  CPL
> >> died as another contributor had a series which went in first...then I
> >> never got back to it.
> >
> >> So for now having the entire U-Boot in runtime space seems reasonable to me.
> >
> >> I'll also mention that it would be nice to have s new-style API
> >> (replacing the old API U-Boot currently has) which uses more of a
> >> module approach. E.g. we could declare that uclass_first_device() is
> >> exported and can be called from outside U-Boot.
> >
> >>
> >> >
> >> > >
> >> > > 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.
> >
> >The current approach is pretty brittle, since it relies on putting
> >some of the U-Boot code into a separate area. There is no good way to
> >know which U-Boot code should be in that area, since we don't create a
> >separate build. If a function calls one that has not been specially
> >marked, or accesses data that is not in the area, then it will crash
> >or hang.
> >
> >So, as I said, I think we need a new build, if we want to avoid all of
> >U-Boot in there. Anything else is hard to maintain.
>
> The EFI runtime is the most security exposed part of U-Boot. We should strive to keep the attack surface small. No matter how we define the runtime (by section assignment as today or by a dedicated build) I would not want to have the driver model in the runtime.
>
> The only drivers that are required by the EBBR are for resetting the system. ARM has PSCI as reset handler, RISC-V has SBI. These are invoked by simple ecalls.

So why not have Linux do it? Why do we need the runtime at all?

But from the other POV, what if this expands? We are creating a little
runtime stub without driver model? I suppose it will work until it
doesn't.

>
> Any runtime device drivers for variable storage should not be in the U-Boot runtime but live in the secure world (e.g. OP-TEE). FF-A is the new  ARM protocol for talking to the secure world and hence fits into the picture.

OK. This is all very complicated, of course. But OK.

>
> @Abdellatif
>
> Does an OP-TEE module for managing EFI variables via FF-A already exist? For QEMU?
>
> Best regards
>
> Heinrich
>
> >
> >>
> >> [...]
> >>
> >> [0] https://www.youtube.com/watch?v=UdQk0SCUAlA
> >> [1] https://lpc.events/event/17/contributions/1653/attachments/1338/2682/Plumbers%20-%20EFI%20setvariable%20problems%20and%20solutions.pdf
> >> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c44b6be62e8dd4ee0a308c36a70620613e6fc55f
> >>
> >

Regards,
Simon