efi: Set Variable Runtime implementation

[Simon Glass]

Hi Shantur,

On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i at shantur.com> wrote:
>
> + Simon as he seems to have done a lot of work in the driver model.
>
> On Mon, Nov 27, 2023 at 10:12 AM Shantur Rathore <i at shantur.com> wrote:
> >
> > Hi Ilias,
> >
> > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hi Shantur
> > >
> > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i at shantur.com> wrote:
> > > >
> > > > Hi Peter,
> > > >
> > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson at gmail.com> wrote:
> > > > >
> > > > > Hi Shantur,
> > > > >
> > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i at shantur.com> wrote:
> > > > > >
> > > > > > Hi Ilias,
> > > > > >
> > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > <ilias.apalodimas at linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Shantur
> > > > > > >
> > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i at shantur.com> wrote:
> > > > > > > >
> > > > > > > > Hi Heinrich,
> > > > > > > >
> > > > > > > > I am trying to work out how to enable the SetVariableRT service in
> > > > > > > > U-Boot and came across your patch [1] which initially had the
> > > > > > > > SetVariable RT service enabled in EFI but in the final patch this was
> > > > > > > > removed.
> > > > > > > > I am hoping to implement it on top of the SPI Flash EFI store [2] to
> > > > > > > > be able to set Boot order and boot items from Linux the UEFI way.
> > > > > > > >
> > > > > > > > Can I pick your brain on why it was dropped in the patch?
> > > > > > > > Is there any limitation in SetVariableRT service ?
> > > > > > >
> > > > > > > I recently had a talk about it in Plumbers [0]. Generally speaking, RT
> > > > > > > + hardware owned by the kernel is a very weird combination since you
> > > > > > > can't guarantee exclusive access to the flash or the bus and you have
> > > > > > > to preserve a *lot* of code alive in u-boot.
> > > > > > >
> > > > > > > I'll respond to your v1 patchset and we can discuss details there as well.
> > > > > > >
> > > > > > > [0] https://lpc.events/event/17/contributions/1653/
> > > > > >
> > > > > > Thanks for the background and helping me understand the problem.
> > > > > > Makes me wonder how things work in the PC world.
> > > > > > U-boot being only ~1MB, can we not leave it all in memory and maybe
> > > > > > just disable SPI access to Linux.
> > >
> > > That would work, but you cant guarantee Linux wont enable the SPI flash.
> > >
> > > > >
> > > > > That's basically it, on x86 there's specific HW that's owned by
> > > > > firmware, I don't know the exact low level details of how that works.
> > > > >
> > > > > I think x86 devices generally use eSPI for this HW [1] but I don't
> > > > > know the low level details. The Arm SBSA (Server HW spec) and SBBR
> > > > > (Server Base Boot Requirements) specs that are key to ServerReady may
> > > > > go into some details too if you're curious.
> > >
> > > On X86 the SPI flash is handled entirely by the firmware and SMM. You
> > > can find more details here [0]
> >
> > Thanks for more info.
> >
> > >
> > > >
> > > > Thanks,
> > > > I think the firmware is still accessible to PCs as one could update the firmware
> > > > in Windows so Windows has access to that device.
> > > >
> > > > I had some try myself and found that setting a variable to memory backed storage
> > > > is doable with SetVariable call but we want to store it in any
> > > > non-volatile storage
> > > > things really don't look good.
> > > >
> > > > To be able to write SetVariable to any device, the whole u-boot driver
> > > > model would need
> > > > to be kept in memory, might as well just keep the whole u-boot in
> > > > memory at this point, it's anyway small.
> > > > I don't have much knowledge on how to or pros and cons of doing this.
> > >
> > > The major problem here is who owns the hardware. With the SPI flash
> > > implementation as well as the RPMB implementation Linux owns that
> > > flash.
> > > For the RPMB we've introduced a mechanism so the kernel replaces the
> > > runtime calls with internal functions [1].  I think we should come up
> > > with a similar architecture for SPI. In any case we should keep in
> > > mind that setting authenticated EFI variables should be forbidden on
> > > the file/SPI backends since they are not really secure.
> > >
> >
> > Thanks, I understand now that we can't use SPI flash for saving secure
> > variables and stop Linux from accessing it.
> > My requirement is to be able to save non-Secure boot related variables
> > ( BootOrder, BootNext and BootOptions ).
> > For this purpose as we don't need secure channel and to be compatible
> > with current Linux versions I started
> > implementing SetVariable in runtime in [1]
> > I was able to get it working until it's ready to write stuff into SPI Flash.

Yes, this makes sense to me and we don't need secure vars for these
features. They are really just hints from the OS or user.

> > To be able to use SPI Flash, runtime call needs to access the drivers
> > and this needs the whole driver-model to be in
> > efi runtime memory makes me think would it make sense to keep the
> > whole u-boot in efi runtime memory or just
> > driver model and all SPI drivers for now and keep adding other drivers
> > when needed like RPMB.

I don't fully agree with this. The OS is well able to access SPI flash
or any other device. There is no need to ask the firmware to do it,
unless there is some other reason. I can understand calling into a
secure OS, or using a TPM, but for SPI flash this doesn't make much
sense to me.

> >
> > I need some pointers to what would be the best approach accessing
> > hardware from runtime.

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.

> >
> > [1] - https://github.com/shantur/u-boot/tree/spi-flash-runtime-setvariable
> >
> > Kind regards,
> > Shantur

Regards,
Simon