efi: Set Variable Runtime implementation

[Peter Robinson]

Hi Shantur,

> > > > > 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'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.
>
> 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 believe in most cases what happens is the OS sets up the update
ready so the firmware itself can apply it on a reboot. This is how
UEFI Capsule update works.

If you run "fwupdmgr security" on a Linux system you can see some
security features like "SPI lock" and "SPI write". I have at least one
x86 hobbyist system where you can enable/disable the SPI access/lock
but even with that the firmware update is done from the UEFI shell.

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

I believe when set variable is running there is a small subset of
U-Boot in memory but Ilias will definitely know the details there.

> >
> > BTW I plan to test your other patches on the Pinebook Pro.
> >
> > [1] https://www.totalphase.com/blog/2021/09/what-is-the-espi-protocol-and-how-does-it-improve-upon-lpc/
>
> Thanks, that would be helpful.
> I am particularly keen on the usb patch here
> https://patchwork.ozlabs.org/project/uboot/patch/20231110141311.512334-1-i@shantur.com/

I'll take a look.

Peter