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

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

[Abdellatif El Khlifi]

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

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 ?

[1]: https://lore.kernel.org/all/CAPnjgZ21qLnSFcCJ9rPQXEfQf-NjMBF3kYUDBBOc6WUQXQtDEA@mail.gmail.com/

Cheers,
Abdellatif

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

[Mark Kettenis]

> 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...

> 
> 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.

> 
> [1]: https://lore.kernel.org/all/CAPnjgZ21qLnSFcCJ9rPQXEfQf-NjMBF3kYUDBBOc6WUQXQtDEA@mail.gmail.com/
> 
> Cheers,
> Abdellatif
> 

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

[Ilias Apalodimas]

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.

>
> >
> > 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.

[...]

[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


/Ilias

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

[Simon Glass]

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.

>
> [...]
>
> [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

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

[Heinrich Schuchardt]

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? 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

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

[Michael Walle]

Hi Heinrich,

> 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.

What if I just want a simple embedded boot stack where I don't
want any secure world and just want to be able to boot a COTS linux
distribution via EFI?

Assuming, that there might be a simple dedicated EEPROM to store the
variables which is not exposed to linux, is that something which would
be rejected by u-boot mainline now?

-michael

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

[Mark Kettenis]

> From: Michael Walle <mwalle@kernel.org>
> Date: Tue, 19 Dec 2023 11:11:24 +0100
> 
> Hi Heinrich,

Hi Michael,

> > 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.
> 
> What if I just want a simple embedded boot stack where I don't
> want any secure world and just want to be able to boot a COTS linux
> distribution via EFI?

That already works for many Linux distros.  As long as the distro
installs the appropriate BOOTxxx.EFI file you don't actually need to
set any EFI variables for the OS to boot.  It can't get any simpler
than that.  Of the main Linux distros it seems that only Debian
doesn't do this.  Someone should probably lobby Debian to do this as
well as it would mean that Debian would just work on an EBBR compliant
system.

Things get more complicated if you want to install multiple OSes.
Then having EFI variable support makes things a lot more
straightforward.

And of course EFI secure boot needs EFI variable support as well (with
proper support) for authenticated EFI variables.  But IMHO that no
longer falls into "simple embedded boot stack" territory.

> Assuming, that there might be a simple dedicated EEPROM to store the
> variables which is not exposed to linux, is that something which would
> be rejected by u-boot mainline now?

Not necessarily.  But such an approach will have limitations:

* Completely hiding the EEPROM from the OS may be hard.  Even if you
  have a dedicated SPI controller for the EEPROM things like the SPI
  bus clock or power domains may still be under OS control.

* It is not possible to properly implement authenticated variables for
  secure boot if the EEPROM and associated hardware is just removed
  from the device tree but still accessable to the OS.  An
  implementation that pretends the variables are "secure" will
  probably be rejected.

Cheers,

Mark

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

[Michael Walle]

Hi Mark,

>> > 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.
>> 
>> What if I just want a simple embedded boot stack where I don't
>> want any secure world and just want to be able to boot a COTS linux
>> distribution via EFI?
> 
> That already works for many Linux distros.  As long as the distro
> installs the appropriate BOOTxxx.EFI file you don't actually need to
> set any EFI variables for the OS to boot.  It can't get any simpler
> than that.  Of the main Linux distros it seems that only Debian
> doesn't do this.  Someone should probably lobby Debian to do this as
> well as it would mean that Debian would just work on an EBBR compliant
> system.

I know. Last time I checked CentOS (or was it Ubuntu?) tried to
set EFI variables and the installer just failed. Might be fixed now,
though.

> Things get more complicated if you want to install multiple OSes.
> Then having EFI variable support makes things a lot more
> straightforward.
> 
> And of course EFI secure boot needs EFI variable support as well (with
> proper support) for authenticated EFI variables.  But IMHO that no
> longer falls into "simple embedded boot stack" territory.

Thats clear.

>> Assuming, that there might be a simple dedicated EEPROM to store the
>> variables which is not exposed to linux, is that something which would
>> be rejected by u-boot mainline now?
> 
> Not necessarily.  But such an approach will have limitations:
> 
> * Completely hiding the EEPROM from the OS may be hard.  Even if you
>   have a dedicated SPI controller for the EEPROM things like the SPI
>   bus clock or power domains may still be under OS control.

Fair point, but I was thinking about the ls1028a for example, where - if
I remember correctly - there was one dedicated i2c controller in a sense
of isolation, probably to use with a secure OS. Also there is no dynamic
clocking.

So, technically it should be possible, even with a low overhead, like no
device model etc, which could reside in the efi os services. Just 
testing
the waters here, not that I'm interested in adding support for that in
u-boot. Just a bit concerned that it (EFI variables) will only work with
a full stack (tf-a, optee) in the future.

> * It is not possible to properly implement authenticated variables for
>   secure boot if the EEPROM and associated hardware is just removed
>   from the device tree but still accessable to the OS.  An
>   implementation that pretends the variables are "secure" will
>   probably be rejected.

Sure. I excluded any secure stuff. But, with that i2c controller i was
talking about earlier, it should be possible to mark it as EL3 access
only.

Thanks,
-michael

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

On Tue, Dec 19, 2023 at 01:47:07PM +0100, Michael Walle wrote:
> Hi Mark,
> 
> > > > 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.
> > > 
> > > What if I just want a simple embedded boot stack where I don't
> > > want any secure world and just want to be able to boot a COTS linux
> > > distribution via EFI?
> > 
> > That already works for many Linux distros.  As long as the distro
> > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > set any EFI variables for the OS to boot.  It can't get any simpler
> > than that.  Of the main Linux distros it seems that only Debian
> > doesn't do this.  Someone should probably lobby Debian to do this as
> > well as it would mean that Debian would just work on an EBBR compliant
> > system.
> 
> I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> set EFI variables and the installer just failed. Might be fixed now,
> though.
> 
> > Things get more complicated if you want to install multiple OSes.
> > Then having EFI variable support makes things a lot more
> > straightforward.
> > 
> > And of course EFI secure boot needs EFI variable support as well (with
> > proper support) for authenticated EFI variables.  But IMHO that no
> > longer falls into "simple embedded boot stack" territory.
> 
> Thats clear.
> 
> > > Assuming, that there might be a simple dedicated EEPROM to store the
> > > variables which is not exposed to linux, is that something which would
> > > be rejected by u-boot mainline now?
> > 
> > Not necessarily.  But such an approach will have limitations:
> > 
> > * Completely hiding the EEPROM from the OS may be hard.  Even if you
> >   have a dedicated SPI controller for the EEPROM things like the SPI
> >   bus clock or power domains may still be under OS control.
> 
> Fair point, but I was thinking about the ls1028a for example, where - if
> I remember correctly - there was one dedicated i2c controller in a sense
> of isolation, probably to use with a secure OS. Also there is no dynamic
> clocking.
> 
> So, technically it should be possible, even with a low overhead, like no
> device model etc, which could reside in the efi os services. Just testing
> the waters here, not that I'm interested in adding support for that in
> u-boot. Just a bit concerned that it (EFI variables) will only work with
> a full stack (tf-a, optee) in the future.

I would fully expect us to continue to support the case you're
describing. It just may have limitations or as you describe
implementation work needing to be done to support handling security
differently. But it should (*cough*) be abstracted such that it's
possible to do so.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Ilias Apalodimas]

Hi Michael

On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle@kernel.org> wrote:
>
> Hi Mark,
>
> >> > 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.
> >>
> >> What if I just want a simple embedded boot stack where I don't
> >> want any secure world and just want to be able to boot a COTS linux
> >> distribution via EFI?
> >
> > That already works for many Linux distros.  As long as the distro
> > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > set any EFI variables for the OS to boot.  It can't get any simpler
> > than that.  Of the main Linux distros it seems that only Debian
> > doesn't do this.  Someone should probably lobby Debian to do this as
> > well as it would mean that Debian would just work on an EBBR compliant
> > system.
>
> I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> set EFI variables and the installer just failed. Might be fixed now,
> though.

It's not. The error message is less scary in distros nowadays, but
setting the variable for Boot0000 is still not working. That being
said I have a plan to fix it for variables stored in a file, that's
why we standardized the efi variable format in EBBR.

>
> > Things get more complicated if you want to install multiple OSes.
> > Then having EFI variable support makes things a lot more
> > straightforward.
> >
> > And of course EFI secure boot needs EFI variable support as well (with
> > proper support) for authenticated EFI variables.  But IMHO that no
> > longer falls into "simple embedded boot stack" territory.
>
> Thats clear.
>
> >> Assuming, that there might be a simple dedicated EEPROM to store the
> >> variables which is not exposed to linux, is that something which would
> >> be rejected by u-boot mainline now?

Depends by 'not exposed'. And keep in mind that with a simple SPI
flash you also have to worry about easy hardware attacks. E.g. someone
replaces your SPI flash with his version of authenticated EFI
variables.

We have patches on the ML adding variable support to SPI a SPI flash,
but excluding authenticated variables. [0]

> >
> > Not necessarily.  But such an approach will have limitations:
> >
> > * Completely hiding the EEPROM from the OS may be hard.  Even if you
> >   have a dedicated SPI controller for the EEPROM things like the SPI
> >   bus clock or power domains may still be under OS control.
>
> Fair point, but I was thinking about the ls1028a for example, where - if
> I remember correctly - there was one dedicated i2c controller in a sense
> of isolation, probably to use with a secure OS. Also there is no dynamic
> clocking.
>
> So, technically it should be possible, even with a low overhead, like no> device model etc, which could reside in the efi os services. Just
> testing
> the waters here, not that I'm interested in adding support for that in
> u-boot. Just a bit concerned that it (EFI variables) will only work with
> a full stack (tf-a, optee) in the future.
>
> > * It is not possible to properly implement authenticated variables for
> >   secure boot if the EEPROM and associated hardware is just removed
> >   from the device tree but still accessable to the OS.  An
> >   implementation that pretends the variables are "secure" will
> >   probably be rejected.

That would be an EEPROM dedicated to the secure world. At some point,
I got involved with an EDK2 implementation for supporting EFI
variables on a SolidRun honeycomb. We even fixed SetVariableRT and we
run the whole thing via OP-TEE (just like we do for RPMB in U-Boot).
So this (minus the physical attacks) is quite secure, because even the
code running the crypto checks for authenticating variables, runs
isolated in the secure world.

It's been a while, but IIRC StMM has FVBs (firmware block protocols)
in EDK2 parlance. We have StMM FVBs for RPMBs and EEPROMs and we can
launch StMM from OP-TEE. Adding runtime variable support for the RPMB
is close to impossible if you want to adhere to the EFI spec, but for
it's doable for the EEPROM.

Ping me on IRC if you start adding support, I can help.

>
> Sure. I excluded any secure stuff. But, with that i2c controller i was
> talking about earlier, it should be possible to mark it as EL3 access
> only.

Yes, there was a slight implication. NXP some had timer on that I2C or
something, but it's been too long to remember the details...

>
> Thanks,
> -michael

Thanks
/Ilias

[0] https://lore.kernel.org/u-boot/20231126220836.374956-2-i@shantur.com/

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

[Peter Robinson]

On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Michael
>
> On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle@kernel.org> wrote:
> >
> > Hi Mark,
> >
> > >> > 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.
> > >>
> > >> What if I just want a simple embedded boot stack where I don't
> > >> want any secure world and just want to be able to boot a COTS linux
> > >> distribution via EFI?
> > >
> > > That already works for many Linux distros.  As long as the distro
> > > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > > set any EFI variables for the OS to boot.  It can't get any simpler
> > > than that.  Of the main Linux distros it seems that only Debian
> > > doesn't do this.  Someone should probably lobby Debian to do this as
> > > well as it would mean that Debian would just work on an EBBR compliant
> > > system.
> >
> > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > set EFI variables and the installer just failed. Might be fixed now,
> > though.
>
> It's not. The error message is less scary in distros nowadays, but
> setting the variable for Boot0000 is still not working. That being
> said I have a plan to fix it for variables stored in a file, that's
> why we standardized the efi variable format in EBBR.

The actual error is coming from efibootmgr, which is the tool trying
to set the variable and is just passed up to installers.

It's now mostly a soft error as if you confirm the error the device
still boots via the EFI Fallback methods.

> >
> > > Things get more complicated if you want to install multiple OSes.
> > > Then having EFI variable support makes things a lot more
> > > straightforward.
> > >
> > > And of course EFI secure boot needs EFI variable support as well (with
> > > proper support) for authenticated EFI variables.  But IMHO that no
> > > longer falls into "simple embedded boot stack" territory.
> >
> > Thats clear.
> >
> > >> Assuming, that there might be a simple dedicated EEPROM to store the
> > >> variables which is not exposed to linux, is that something which would
> > >> be rejected by u-boot mainline now?
>
> Depends by 'not exposed'. And keep in mind that with a simple SPI
> flash you also have to worry about easy hardware attacks. E.g. someone
> replaces your SPI flash with his version of authenticated EFI
> variables.
>
> We have patches on the ML adding variable support to SPI a SPI flash,
> but excluding authenticated variables. [0]
>
> > >
> > > Not necessarily.  But such an approach will have limitations:
> > >
> > > * Completely hiding the EEPROM from the OS may be hard.  Even if you
> > >   have a dedicated SPI controller for the EEPROM things like the SPI
> > >   bus clock or power domains may still be under OS control.
> >
> > Fair point, but I was thinking about the ls1028a for example, where - if
> > I remember correctly - there was one dedicated i2c controller in a sense
> > of isolation, probably to use with a secure OS. Also there is no dynamic
> > clocking.
> >
> > So, technically it should be possible, even with a low overhead, like no> device model etc, which could reside in the efi os services. Just
> > testing
> > the waters here, not that I'm interested in adding support for that in
> > u-boot. Just a bit concerned that it (EFI variables) will only work with
> > a full stack (tf-a, optee) in the future.
> >
> > > * It is not possible to properly implement authenticated variables for
> > >   secure boot if the EEPROM and associated hardware is just removed
> > >   from the device tree but still accessable to the OS.  An
> > >   implementation that pretends the variables are "secure" will
> > >   probably be rejected.
>
> That would be an EEPROM dedicated to the secure world. At some point,
> I got involved with an EDK2 implementation for supporting EFI
> variables on a SolidRun honeycomb. We even fixed SetVariableRT and we
> run the whole thing via OP-TEE (just like we do for RPMB in U-Boot).
> So this (minus the physical attacks) is quite secure, because even the
> code running the crypto checks for authenticating variables, runs
> isolated in the secure world.
>
> It's been a while, but IIRC StMM has FVBs (firmware block protocols)
> in EDK2 parlance. We have StMM FVBs for RPMBs and EEPROMs and we can
> launch StMM from OP-TEE. Adding runtime variable support for the RPMB
> is close to impossible if you want to adhere to the EFI spec, but for
> it's doable for the EEPROM.
>
> Ping me on IRC if you start adding support, I can help.
>
> >
> > Sure. I excluded any secure stuff. But, with that i2c controller i was
> > talking about earlier, it should be possible to mark it as EL3 access
> > only.
>
> Yes, there was a slight implication. NXP some had timer on that I2C or
> something, but it's been too long to remember the details...
>
> >
> > Thanks,
> > -michael
>
> Thanks
> /Ilias
>
> [0] https://lore.kernel.org/u-boot/20231126220836.374956-2-i@shantur.com/

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

[Shantur Rathore]

Hi Illias,

On Wed, Dec 20, 2023 at 3:43 PM Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Michael
> >
> > On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle@kernel.org> wrote:
> > >
> > > Hi Mark,
> > >
> > > >> > 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.
> > > >>
> > > >> What if I just want a simple embedded boot stack where I don't
> > > >> want any secure world and just want to be able to boot a COTS linux
> > > >> distribution via EFI?
> > > >
> > > > That already works for many Linux distros.  As long as the distro
> > > > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > > > set any EFI variables for the OS to boot.  It can't get any simpler
> > > > than that.  Of the main Linux distros it seems that only Debian
> > > > doesn't do this.  Someone should probably lobby Debian to do this as
> > > > well as it would mean that Debian would just work on an EBBR compliant
> > > > system.
> > >
> > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > > set EFI variables and the installer just failed. Might be fixed now,
> > > though.
> >
> > It's not. The error message is less scary in distros nowadays, but
> > setting the variable for Boot0000 is still not working. That being
> > said I have a plan to fix it for variables stored in a file, that's
> > why we standardized the efi variable format in EBBR.

Does this mean supporting SetVariableRT for files ?
If yes, would it work without the driver model in runtime?

Kind regards,
Shantur

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

[Ilias Apalodimas]

Hi Shantur

On Thu, 21 Dec 2023 at 00:57, Shantur Rathore <i@shantur.com> wrote:
>
> Hi Illias,
>
> On Wed, Dec 20, 2023 at 3:43 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Michael
> > >
> > > On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle@kernel.org> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > >> > 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.
> > > > >>
> > > > >> What if I just want a simple embedded boot stack where I don't
> > > > >> want any secure world and just want to be able to boot a COTS linux
> > > > >> distribution via EFI?
> > > > >
> > > > > That already works for many Linux distros.  As long as the distro
> > > > > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > > > > set any EFI variables for the OS to boot.  It can't get any simpler
> > > > > than that.  Of the main Linux distros it seems that only Debian
> > > > > doesn't do this.  Someone should probably lobby Debian to do this as
> > > > > well as it would mean that Debian would just work on an EBBR compliant
> > > > > system.
> > > >
> > > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > > > set EFI variables and the installer just failed. Might be fixed now,
> > > > though.
> > >
> > > It's not. The error message is less scary in distros nowadays, but
> > > setting the variable for Boot0000 is still not working. That being
> > > said I have a plan to fix it for variables stored in a file, that's
> > > why we standardized the efi variable format in EBBR.
>
> Does this mean supporting SetVariableRT for files ?
> If yes, would it work without the driver model in runtime?

Yes.

The reasoning here is pretty simple. You can't keep alive drivers etc
for devices that the *kernel* eventually owns. The proposal is to
ignore the EFI spec and teach the kernel to write those directly. We
already do that when the variables are stored in an RPMB, we need to
figure out a decent scalable architecture for the rest.

/Ilias
>
> Kind regards,
> Shantur

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

[Shantur Rathore]

Hi Ilias,

On Thu, Dec 21, 2023 at 6:30 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Shantur
>
> On Thu, 21 Dec 2023 at 00:57, Shantur Rathore <i@shantur.com> wrote:
> >
> > Hi Illias,
> >
> > On Wed, Dec 20, 2023 at 3:43 PM Peter Robinson <pbrobinson@gmail.com> wrote:
> > >
> > > On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
> > > >
> > > > Hi Michael
> > > >
> > > > On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle@kernel.org> wrote:
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > >> > 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.
> > > > > >>
> > > > > >> What if I just want a simple embedded boot stack where I don't
> > > > > >> want any secure world and just want to be able to boot a COTS linux
> > > > > >> distribution via EFI?
> > > > > >
> > > > > > That already works for many Linux distros.  As long as the distro
> > > > > > installs the appropriate BOOTxxx.EFI file you don't actually need to
> > > > > > set any EFI variables for the OS to boot.  It can't get any simpler
> > > > > > than that.  Of the main Linux distros it seems that only Debian
> > > > > > doesn't do this.  Someone should probably lobby Debian to do this as
> > > > > > well as it would mean that Debian would just work on an EBBR compliant
> > > > > > system.
> > > > >
> > > > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > > > > set EFI variables and the installer just failed. Might be fixed now,
> > > > > though.
> > > >
> > > > It's not. The error message is less scary in distros nowadays, but
> > > > setting the variable for Boot0000 is still not working. That being
> > > > said I have a plan to fix it for variables stored in a file, that's
> > > > why we standardized the efi variable format in EBBR.
> >
> > Does this mean supporting SetVariableRT for files ?
> > If yes, would it work without the driver model in runtime?
>
> Yes.
>
> The reasoning here is pretty simple. You can't keep alive drivers etc
> for devices that the *kernel* eventually owns. The proposal is to
> ignore the EFI spec and teach the kernel to write those directly. We
> already do that when the variables are stored in an RPMB, we need to
> figure out a decent scalable architecture for the rest.
>
Thanks for explaining this.
It would be a good idea to provide EFI var storage info like location,
offset, maxsize to linux
and linux can modify vars as required.

Eg.

location=espfile://u-boot-efi.vars offset=0 maxsize=-1
or
location=spi://0 offset=0x3D0000 maxsize=0xFFFF

Then the linux kernel is able to modify vars correctly.
I think SPI might be simpler to implement vs file as there can be.
many different
ESP partitions on multiple drives or no ESP partition at all.

Kind regards,
Shantur

> /Ilias
> >
> > Kind regards,
> > Shantur

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

[Ilias Apalodimas]

[...]

> > > > > > I know. Last time I checked CentOS (or was it Ubuntu?) tried to
> > > > > > set EFI variables and the installer just failed. Might be fixed now,
> > > > > > though.
> > > > >
> > > > > It's not. The error message is less scary in distros nowadays, but
> > > > > setting the variable for Boot0000 is still not working. That being
> > > > > said I have a plan to fix it for variables stored in a file, that's
> > > > > why we standardized the efi variable format in EBBR.
> > >
> > > Does this mean supporting SetVariableRT for files ?
> > > If yes, would it work without the driver model in runtime?
> >
> > Yes.
> >
> > The reasoning here is pretty simple. You can't keep alive drivers etc
> > for devices that the *kernel* eventually owns. The proposal is to
> > ignore the EFI spec and teach the kernel to write those directly. We
> > already do that when the variables are stored in an RPMB, we need to
> > figure out a decent scalable architecture for the rest.
> >
> Thanks for explaining this.
> It would be a good idea to provide EFI var storage info like location,
> offset, maxsize to linux
> and linux can modify vars as required.
>
> Eg.
>
> location=espfile://u-boot-efi.vars offset=0 maxsize=-1
> or
> location=spi://0 offset=0x3D0000 maxsize=0xFFFF
>

Yes, you need the flash, offset and size, but I as trying to figure out if
we hand over those as an EFI config table. I haven't managed to do any
coding though yet.

/Ilias
> Then the linux kernel is able to modify vars correctly.
> I think SPI might be simpler to implement vs file as there can be.
> many different
> ESP partitions on multiple drives or no ESP partition at all.
>
> Kind regards,
> Shantur
>
> > /Ilias
> > >
> > > Kind regards,
> > > Shantur

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

[Abdellatif El Khlifi]

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

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

[Simon Glass]

Hi Heinrich,

On Mon, 18 Dec 2023 at 13:59, Heinrich Schuchardt <xypron.glpk@gmx.de> 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.

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

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

[Abdellatif El Khlifi]

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@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].

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

Cheers,
Abdellatif

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

[Abdellatif El Khlifi]

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@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].
> 
> 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

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

[Heinrich Schuchardt]

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@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].
>>
>> 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.

Best regards

Heinrich

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

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

[Ilias Apalodimas]

On Mon, 8 Jan 2024 at 16:32, Heinrich Schuchardt <xypron.glpk@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@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].
> >>
> >> 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.

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

Regards
/Ilias
>
> Best regards
>
> Heinrich
>
> >>
> >> 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
>

Re: 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@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@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].
> > >>
> > >> 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

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

[Abdellatif El Khlifi]

Hi Mark,

On Thu, Dec 14, 2023 at 05:47:42PM +0100, Mark Kettenis 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...
> 
> > 
> > 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.

That's my preferred solution, thanks.

Cheers,
Abdellatif