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.