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