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

[Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>]

Hi Heinrich,

On Mon, Dec 18, 2023 at 09:59:13PM +0100, Heinrich Schuchardt wrote:
> 
> 
> Am 18. Dezember 2023 16:01:44 MEZ schrieb Simon Glass <sjg@chromium.org>:
> >Hi,
> >
> >On Thu, 14 Dec 2023 at 12:47, Ilias Apalodimas
> ><ilias.apalodimas@linaro.org> wrote:
> >>
> >> Hi Mark, Abdellatif
> >>
> >> On Thu, 14 Dec 2023 at 18:47, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >> >
> >> > > Date: Thu, 14 Dec 2023 15:53:46 +0000
> >> > > From: Abdellatif El Khlifi <abdellatif.elkhlifi@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.
> 
> 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.
> 
> @Abdellatif 
> 
> Does an OP-TEE module for managing EFI variables via FF-A already exist?
> 

Yes, that's available in two ways:

1) The smm-gateway SP from Trusted Services (aka TS) [1] provides EFI variable service over FF-A [2]. It's not OP-TEE specific, it can run on top of any S-EL1 SPMC.
2) StMM

[1]: https://trusted-services.readthedocs.io/en/stable/deployments/secure-partitions.html#smm-gateway
[2]: https://github.com/u-boot/u-boot/blob/master/doc/arch/arm64.ffa.rst

> For QEMU?

Yes, smm-gateway is tested on QEMU through the qemuarm64-secureboot Yocto machine [1].
Also, there is an in-progress PR to add TS on QEMU support in the OP-TEE integration system [2].

[1]: https://git.yoctoproject.org/meta-arm/tree/meta-arm/conf/machine/qemuarm64-secureboot.conf , https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/trusted-services/ts-uefi-test_git.bb
[2]: https://github.com/OP-TEE/build/pull/688

Cheers,
Abdellatif