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 at shantur.com> wrote:
>
> Hi Illias,
>
> On Wed, Dec 20, 2023 at 3:43 PM Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Wed, Dec 20, 2023 at 6:37 AM Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hi Michael
> > >
> > > On Tue, 19 Dec 2023 at 14:47, Michael Walle <mwalle at 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