efi: Set Variable Runtime implementation

[Shantur Rathore]

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