efi: Set Variable Runtime implementation

Mon Dec 4 01:44:26 CET 2023

Hi Shantur,

On Sun, 3 Dec 2023 at 14:51, Shantur Rathore <i at shantur.com> wrote:
>
> Hi Simon,
>
> On Sun, Dec 3, 2023 at 5:44 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Shantur,
> >
> > On Sat, 2 Dec 2023 at 16:03, Shantur Rathore <i at shantur.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > Sure, the OS can write to SPI Flash but the OS won't know what / where to write
> > > that U-Boot will be able to read and use as an EFI variable.
> > > AFAIK, all UEFI firmwares have some non volatile storage where firmware stores
> > > variables. As U-boot doesn't have its own non-volatile storage we want
> > > to allow u-boot to
> > > write EFI variables in SPI.
> > > This is needed to be able to manage EFI boot entries with efibootmgr in Linux.
> >
> > We can pass the offset of the vars to the OS using the devicetree,
> > e.g. using the fixed-partition binding, so then fwupd (or whatever)
> > can do the update.
> >
>
> Sure, we could do this but then this would be a non-standard way of
> managing the
> EFI variables.

Apparently. I keep thinking of this talk:

https://www.youtube.com/watch?v=36myc8wQhLo

This is a longer discussion, but I believe that much of the firmware
design happening today is an unnecessary obfuscation.

Regards,
Simon

>
> > >
> > > Why does he need it, you might think.
> > > My aim is to automate OS deployment on ARM boards for which I use
> > > Canonical MAAS.
> > > As a netinstall process the boot partition is configured as part of install.
> > > As EFI/boot/bootxxxx.efi is optional [0], some distros like debian and
> > > debian based Armbian
> > > don't install EFI/boot/bootxxxx.efi by default, it tries to set a boot
> > > entry with efibootmgr
> > > and can't so I had to disable it.
> > > Now that update nvram is disabled in grub-install, it doesn't set up a
> > > boot variable but
> > > also doesn't install EFI/boot/bootxxxx.efi but EFI/debian/grubxxxx.efi.
> > >
> > > I am able to work around by manually forcing grub-install with --removable param
> > > to force it to install EFI/boot/bootxxxx.efi, so it kinda works.
> > >
> > > This made me think of improvements we can make in u-boot to allow it
> > > function more
> > > like real UEFI firmware where it can.
> >
> > OK, I see.
> >
> > >
> > > > > >
> > > > > > 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.
> > >
> > > I think this is way more deep than my current understanding of the u-boot and
> > > boot process. I might be able to implement this if and when RPMB access is
> > > implemented for OP-TEE based access.
> >
> > Yes...it is a tricky area, but perhaps we can copy what Linux does
> > with the EXPORT_SYMBOL() macro. Anyway, that is for the future
> >
> Maybe, I will park this for now and wait for the OP-TEE RPMB solution.
>
> Kind regards,
> Shantur