Make SetVariableRT mandatory

[apalos]

SetvariableRT was never mandatory and it has been causing a lot of problems wrt to distro installers and capsule update on-disk.

rhboot/efivar#282 is the last piece of the puzzle for u-boot to support setvariable RT regardless of the storage. I think we should in the future make it mandatory

[xypron]

Hello Ilias,

I think this is a valid discussion to have. I confirm that for a distro life would be easier with SetVariable at runtime.

There is no UEFI service called SetVariableRT(). We should refer to SetVariable() at runtime.

If we opt to require SetVariable(), we should also require GetVariable() and GetNextVariable() and possibly QueryVariableInfo() at runtime

With rhboot/efivar#282 there are now two hacked up ways in Linux to implement SetVariable() which both will not work between ExitBootServices() and the operating system being fully set up. Are other relevant operating systems, e.g. BSD and Windows on ARM, expected to support these hacks?

Two weeks ago we discussed if we should allow systems without any runtime time services, specifically without virtual memory services, to be called EBBR compliant (#141) out of security considerations. You now walk into the opposite direction proposing a requirement for run time services after SetVirtualAddressMap(). Have the previous security concerns been misled?

Could you, please, elaborate why you don't like the current capsule on disk implementation in U-Boot (which is ignoring flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in OsIndications).

Best regards

Heinrich

[fozog]

HelloI believe the key question for RT mandatory function is: what is the minimal set of functions required to deal with firmware upgrade commit and rollback ?CheersFFOn 25 Jun 2025, at 01:48, Heinrich Schuchardt ***@***.***> wrote:xypron left a comment (ARM-software/ebbr#143) Hello Ilias, I think this is a valid discussion to have. I confirm that for a distro life would be easier with SetVariable at runtime. There is no UEFI service called SetVariableRT(). We should refer to SetVariable() at runtime. If we opt to require SetVariable(), we should also require GetVariable() and GetNextVariable() and possibly QueryVariableInfo() at runtime With rhboot/efivar#282 there are now two hacked up ways in Linux to implement SetVariable() which both will not work between ExitBootServices() and the operating system being fully set up. Are other relevant operating systems, e.g. BSD and Windows on ARM, expected to support these hacks? Two weeks ago we discussed if we should allow systems without any runtime time services, specifically without virtual memory services, to be called EBBR compliant (#141) out of security considerations. You now walk into the opposite direction proposing a requirement for run time services after SetVirtualAddressMap(). Have the previous security concerns been misled? Could you, please, elaborate why you don't like the current capsule on disk implementation in U-Boot (which is ignoring flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in OsIndications). Best regards Heinrich —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[apalos]

HelloI believe the key question for RT mandatory function is: what is the minimal set of functions required to deal with firmware upgrade commit and rollback ?CheersFFOn 25 Jun 2025, at 01:48,

Hi Francois, if you are referring to https://github.com/apalos/edge-iot-arch-guide/blob/main/source/FWU/MBFW/chapter1-introduction.md then SetVariable at runtime isn't needed. The commit/rollback functionality is triggered by an empty capsule. However, we did have discussions on controlling it via a variable if it's supported

Heinrich Schuchardt @.***> wrote:xypron left a comment (ARM-software/ebbr#143)

Hello Ilias,
I think this is a valid discussion to have. I confirm that for a distro life would be easier with SetVariable at runtime.
There is no UEFI service called SetVariableRT(). We should refer to SetVariable() at runtime.
If we opt to require SetVariable(), we should also require GetVariable() and GetNextVariable() and possibly QueryVariableInfo() at runtime
With rhboot/efivar#282 there are now two hacked up ways in Linux to implement SetVariable() which both will not work between ExitBootServices() and the operating system being fully set up. Are other relevant operating systems, e.g. BSD and Windows on ARM, expected to support these hacks?
Two weeks ago we discussed if we should allow systems without any runtime time services, specifically without virtual memory services, to be called EBBR compliant (#141) out of security considerations. You now walk into the opposite direction proposing a requirement for run time services after SetVirtualAddressMap(). Have the previous security concerns been misled?
Could you, please, elaborate why you don't like the current capsule on disk implementation in U-Boot (which is ignoring flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in OsIndications).
Best regards
Heinrich

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[apalos]

Hi Heinrich

Hello Ilias,

I think this is a valid discussion to have. I confirm that for a distro life would be easier with SetVariable at runtime.

There is no UEFI service called SetVariableRT(). We should refer to SetVariable() at runtime.

If we opt to require SetVariable(), we should also require GetVariable() and GetNextVariable() and possibly QueryVariableInfo() at runtime

With rhboot/efivar#282 there are now two hacked up ways in Linux to implement SetVariable() which both will not work between ExitBootServices() and the operating system being fully set up. Are other relevant operating systems, e.g. BSD and Windows on ARM, expected to support these hacks?

That's a good question. Would documenting the behavior in EBBR help ?

Two weeks ago we discussed if we should allow systems without any runtime time services, specifically without virtual memory services, to be called EBBR compliant (#141) out of security considerations. You now walk into the opposite direction proposing a requirement for run time services after SetVirtualAddressMap(). Have the previous security concerns been misled?

SetVirualAddressMap() is a different story imho, because the design itself is very peculiar and requires messing around with the mmu before exitbootservices. Also OS'es work seamlessly without it assuming the address space is big enough to map runtime services as 1:1. That's not the case with Setvariable at runtime.

Could you, please, elaborate why you don't like the current capsule on disk implementation in U-Boot (which is ignoring flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in OsIndications).

It's not ignoring the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED I don't like. I think that deviation from the spec is trivial and since the capsule is deleted after the update has no side effects.
The problem I see comes from the fact that in order to trigger a capsule update you need to have a valid boot option within the same ESP wiith your capsule. Since the OS'es can't set Boot0000 to SHIM, and rely on finding the default bootXXX.efi to boot, installing a capsule to \EFI\UpdateCapsule does not work out of the box. You have to manually set that (or BootNext) at boot time to trigger this. Perhaps we should also ignore the 'valid boot option' requirement if EFI_IGNORE_OS_INDICATIONS is selected and just scan that folder?

Regards
/Ilias

Best regards

Heinrich

[nullr0ute]

With rhboot/efivar#282 there are now two hacked up ways in Linux to implement SetVariable() which both will not work between ExitBootServices() and the operating system being fully set up. Are other relevant operating systems, e.g. BSD and Windows on ARM, expected to support these hacks?

Windows on ARM isn't supportable by EBBR due to the use/requirement of DeviceTree so it's a moot point in this discussion. I'm sure someone from BSD can comment on their thoughts here.

[ricardosalveti]

I'm looking at adding support in systemd for saving the efivar content similarly to the way done at rhboot/efivar#282 for our qualcomm edk2-based firmware (which follows the same u-boot implementation), and noticed that we don't have much more described besides https://github.com/ARM-software/ebbr/blob/main/source/chapter5-variable-storage.rst. Should we make SetVariableRT mandatory and update variable-storage to point to the implementation done by u-boot (RTStorageVolatile and VarToFile)?

It would be nice for this to be described outside u-boot as we can have similar implementations coming from other bootloader projects.

[apalos]

noticed

Chapter5 only defines the format storage, which in this case is irrelevant as the firmware dictates the format in it's VarToFile variable. I am happy to discuss this on the next call. Can you create a PR describing the spec changes?

[vstehle]

Hi @ricardosalveti and @apalos, after discussing during the EBBR call of Jul 15 with @xypron we have some questions:

• What and when is systemd writing to the UEFI variables?
• Is systemd not using the efivar library?

Please let us know if this topic is still relevant. Thanks!

[ricardosalveti]

Hi @ricardosalveti and @apalos, after discussing during the EBBR call of Jul 15 with @xypron we have some questions:

• What and when is systemd writing to the UEFI variables?

The systemd PR I was talking about: systemd/systemd#42905

It writes in multiple locations, but one easy one that is commonly used is via bootctl set-default/set-oneshot/ set-timeout.

• Is systemd not using the efivar library?

Please let us know if this topic is still relevant. Thanks!

No, it has its own implementation, which was a bit of a surprise for me when validating with bootctl.

[ricardosalveti]

noticed

Chapter5 only defines the format storage, which in this case is irrelevant as the firmware dictates the format in it's VarToFile variable. I am happy to discuss this on the next call. Can you create a PR describing the spec changes?

Will do, things are slower over the past few days due vacation, but should get to this one tomorrow.

[ricardosalveti]

Created #169, but only making get/set required for file-backed variable stores, instead of making all mandatory, we can discuss it further as needed.