efi: Set Variable Runtime implementation

efi: Set Variable Runtime implementation

[Shantur Rathore]

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 ?

Kind regards,
Shantur

[1] : https://patches.linaro.org/project/u-boot/patch/20200331060541.4212-1-xypron.glpk@gmx.de/
[2] : https://patchwork.ozlabs.org/project/uboot/list/?series=383699

Re: efi: Set Variable Runtime implementation

[Ilias Apalodimas]

Hi Shantur

On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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/

Cheers
/Ilias
>
> Kind regards,
> Shantur
>
> [1] : https://patches.linaro.org/project/u-boot/patch/20200331060541.4212-1-xypron.glpk@gmx.de/
> [2] : https://patchwork.ozlabs.org/project/uboot/list/?series=383699

Re: efi: Set Variable Runtime implementation

[Shantur Rathore]

Hi Ilias,

On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Shantur
>
> On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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.
I might be talking rubbish, just thinking what weird ways it can be worked.

Regards,
Shantur

Re: efi: Set Variable Runtime implementation

[Peter Robinson]

Hi Shantur,

On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
>
> Hi Ilias,
>
> On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Shantur
> >
> > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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'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.

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/

Re: efi: Set Variable Runtime implementation

[Shantur Rathore]

Hi Peter,

On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Shantur,
>
> On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> >
> > Hi Ilias,
> >
> > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Shantur
> > >
> > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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'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 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.

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

Kind regards,
Shantur

Re: 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

Re: efi: Set Variable Runtime implementation

[Ilias Apalodimas]

Hi Shantur

On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
>
> Hi Peter,
>
> On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> >
> > Hi Shantur,
> >
> > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
> > > >
> > > > Hi Shantur
> > > >
> > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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,
> 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.

>
> >
> > 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/
>
> Kind regards,
> Shantur

Regards
/Ilias
[0] https://www.intel.com/content/www/us/en/content-details/671120/a-tour-beyond-bios-uefi-authenticated-variables-in-smm-with-edk-ii.html?wapkw=vincent%20zimmer
[1] https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.kojima@linaro.org/

Re: efi: Set Variable Runtime implementation

[Shantur Rathore]

Hi Ilias,

On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Shantur
>
> On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> >
> > Hi Peter,
> >
> > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > >
> > > Hi Shantur,
> > >
> > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > >
> > > > Hi Ilias,
> > > >
> > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > <ilias.apalodimas@linaro.org> wrote:
> > > > >
> > > > > Hi Shantur
> > > > >
> > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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

Re: 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@shantur.com> wrote:
>
> Hi Ilias,
>
> On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Shantur
> >
> > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > >
> > > Hi Peter,
> > >
> > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > >
> > > > Hi Shantur,
> > > >
> > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > >
> > > > > > Hi Shantur
> > > > > >
> > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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

Re: efi: Set Variable Runtime implementation

[Simon Glass]

Hi Shantur,

On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i@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@shantur.com> wrote:
> >
> > Hi Ilias,
> >
> > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Shantur
> > >
> > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > > >
> > > > Hi Peter,
> > > >
> > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > >
> > > > > Hi Shantur,
> > > > >
> > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > > >
> > > > > > Hi Ilias,
> > > > > >
> > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Shantur
> > > > > > >
> > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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

Re: efi: Set Variable Runtime implementation

[Shantur Rathore]

Hi Simon,

On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Shantur,
>
> On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i@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@shantur.com> wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
> > > >
> > > > Hi Shantur
> > > >
> > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > > > >
> > > > > Hi Peter,
> > > > >
> > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > > >
> > > > > > Hi Shantur,
> > > > > >
> > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > > > >
> > > > > > > Hi Ilias,
> > > > > > >
> > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Shantur
> > > > > > > >
> > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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.

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.

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

[0] - https://www.rodsbooks.com/efi-bootloaders/principles.html

Kind Regards,
Shantur

Re: efi: Set Variable Runtime implementation

[Simon Glass]

Hi Shantur,

On Sat, 2 Dec 2023 at 16:03, Shantur Rathore <i@shantur.com> wrote:
>
> Hi Simon,
>
> On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Shantur,
> >
> > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i@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@shantur.com> wrote:
> > > >
> > > > Hi Ilias,
> > > >
> > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > > > <ilias.apalodimas@linaro.org> wrote:
> > > > >
> > > > > Hi Shantur
> > > > >
> > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > > > > >
> > > > > > Hi Peter,
> > > > > >
> > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > > > >
> > > > > > > Hi Shantur,
> > > > > > >
> > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > > > > >
> > > > > > > > Hi Ilias,
> > > > > > > >
> > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Shantur
> > > > > > > > >
> > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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.

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


>
> [0] - https://www.rodsbooks.com/efi-bootloaders/principles.html
>
> Kind Regards,
> Shantur

Re: efi: Set Variable Runtime implementation

[Shantur Rathore]

Hi Simon,

On Sun, Dec 3, 2023 at 5:44 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Shantur,
>
> On Sat, 2 Dec 2023 at 16:03, Shantur Rathore <i@shantur.com> wrote:
> >
> > Hi Simon,
> >
> > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Shantur,
> > >
> > > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i@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@shantur.com> wrote:
> > > > >
> > > > > Hi Ilias,
> > > > >
> > > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > >
> > > > > > Hi Shantur
> > > > > >
> > > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > > > > > >
> > > > > > > Hi Peter,
> > > > > > >
> > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Shantur,
> > > > > > > >
> > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Ilias,
> > > > > > > > >
> > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Shantur
> > > > > > > > > >
> > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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.

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

Re: efi: Set Variable Runtime implementation

[Simon Glass]

Hi Shantur,

On Sun, 3 Dec 2023 at 14:51, Shantur Rathore <i@shantur.com> wrote:
>
> Hi Simon,
>
> On Sun, Dec 3, 2023 at 5:44 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Shantur,
> >
> > On Sat, 2 Dec 2023 at 16:03, Shantur Rathore <i@shantur.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Dec 1, 2023 at 6:44 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Shantur,
> > > >
> > > > On Mon, 27 Nov 2023 at 10:27, Shantur Rathore <i@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@shantur.com> wrote:
> > > > > >
> > > > > > Hi Ilias,
> > > > > >
> > > > > > On Mon, Nov 27, 2023 at 7:16 AM Ilias Apalodimas
> > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Shantur
> > > > > > >
> > > > > > > On Sun, 26 Nov 2023 at 12:33, Shantur Rathore <i@shantur.com> wrote:
> > > > > > > >
> > > > > > > > Hi Peter,
> > > > > > > >
> > > > > > > > On Sat, Nov 25, 2023 at 6:19 AM Peter Robinson <pbrobinson@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Shantur,
> > > > > > > > >
> > > > > > > > > On Fri, Nov 24, 2023 at 11:55 PM Shantur Rathore <i@shantur.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Ilias,
> > > > > > > > > >
> > > > > > > > > > On Fri, Nov 24, 2023 at 10:50 PM Ilias Apalodimas
> > > > > > > > > > <ilias.apalodimas@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Shantur
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 24 Nov 2023 at 18:51, Shantur Rathore <i@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