efi: Set Variable Runtime implementation

[Shantur Rathore]

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.
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 need some pointers to what would be the best approach accessing
hardware from runtime.

[1] - https://github.com/shantur/u-boot/tree/spi-flash-runtime-setvariable

Kind regards,
Shantur