All runtime services optional after ExitBootServices()

[vstehle]

With this change we would have no more runtime service required after ExitBootServices().

Our requirement dates back from before UEFI version 2.8, which introduced the RT properties table and allowed the UNSUPPORTED return code for the runtime services.

This would be better aligned to what UEFI requires now. Also, making sure that we can build compliant systems with zero service at runtime is interesting for safety and realtime.

[xypron]

Linux may boot with SetVirtualAddressMap(), ConvertPointer() but we cannot expect all OSes to be the same.
Therefore I would not consider these as dispensable.

[vstehle]

Action for this pull request after the EBBR call of Apr 23: investigate a bit more.

• Do we pass SCT if we do not have those services?
• Do we have enough to boot Windows today? Even with ACPI?
• Check if BSD would be happy without SetVirtualAddressMap() & ConvertPointer()

[glikely]

I have concerns about this. There should be no reason to relax UEFI rules further. If runtime services are not wanted by the OS, the OS is already able to simply never call into them.

What is driving this proposed change?

[nullr0ute]

* Do we have enough to boot Windows today? Even with ACPI?

What's Windows got to do with EBBR? EBBR is about device tree, so not sure how ACPI or Windows comes in here?

[vstehle]

I have concerns about this. There should be no reason to relax UEFI rules further. If runtime services are not wanted by the OS, the OS is already able to simply never call into them.

What is driving this proposed change?

Hi @glikely,
I certainly agree that the OS can simply not use those two SetVirtualAddressMap() & ConvertPointer() runtime services (as demonstrated by Linux efi=novamap).

• As it is now, EBBR requires the firmware to implement those two services at runtime.
• UEFI does not require those two services anymore since v2.8 thanks to the introduction of the EFI_RT_PROPERTIES_TABLE and allowing those two services to return EFI_UNSUPPORTED.

This means that because UEFI has moved, EBBR is currently stricter than UEFI on that topic (!)
The motivations to relax the requirements in EBBR are thus the following:

• Align EBBR on UEFI a bit more to not be stricter but only a subset.
• Allow firmware to not implement the two services at all (while still allowing to implement).

Allowing a firmware to not implement those two services is interesting:

• In general to reduce bug (which @apalos has highlighted in some calls)
• And also for safety (in automotive for example), where less code present at runtime means less audit effort.

Let me know if any of this does not make sense.

[vstehle]

What's Windows got to do with EBBR? EBBR is about device tree, so not sure how ACPI or Windows comes in here?

Hi @nullr0ute,
Thanks for looking into this.
Currently EBBR allows either Devicetree or ACPI (but forbids having both).
Others might remember better, but I think that the intention of keeping ACPI support was to not forbid OSes such as Windows intentionally.
Hence the question whether the SetVirtualAddressMap() & ConvertPointer() services are important to such OSes.

[glikely]

This means that because UEFI has moved, EBBR is currently stricter than UEFI on that topic (!) The motivations to relax the requirements in EBBR are thus the following:

Gotcha. That makes sense. Since the entire column is all optionals now, should the column be removed entirely from EBBR?

[glikely]

Actually, no, that doesn't make sense. EBBR should be stricter that UEFI on this point. Part of the intent of EBBR is to lay out a minimum level of functionality that allows a 3rd party OS to mange the platform. The options runtime services were made optional early on to pragmatically enable platforms, but it was never a good solution and the early intent was to start tightening the requirements as U-Boot an other implementations became more mature.

[apalos]

@vstehle I am not sure about this. SetVariableRT has proven problematic over the years -- e.g capsule update on disk support & distro installers need it

[vstehle]

SetVariableRT has proven problematic over the years

Hi @apalos, thanks for having a look.

Currently, SetVariable() is optional at runtime in EBBR.
This pull request is not changing that.

Is your comment more about the general direction, please?

[vstehle]

Here are some preliminary results of investigations:

• All Linux distros tested cope nicely with no SetVirtualAddressMap() and ConvertPointer() services.
• Same for Xen and OpenBSD.
• FreeBSD and NetBSD seem to call into the services in all cases (they might not know about the RT Properties Table) and I have yet to see how they deal with EFI_UNSUPPORTED.

[vstehle]

Summary of my investigations:

OS	Calls SetVirtualAddressMap()?	Happy when EFI_UNSUPPORTED is returned?	Takes RT Properties Table into account?	RT Properties Table GUID present in binary?	Sources
Linux 6.14	Sometimes	Yes	Yes	Yes (Image)	arm64.c, fdt.c, efi-stub.c
FreeBSD 14.2	Yes	Somewhat (ignores return code)	No	No (bootaa64.efi)	bootinfo.c
NetBSD 9.4	Yes	No	No	No (bootaa64.efi)	efifdt.c
OpenBSD 7.7	No	-	-	No (bootaa64.efi)	efiboot.c
Xen 4.14	No	-	-	No (xen.efi)	boot.c
Windows 11	Yes	No	Probably not	No (bootaa64.efi)	-

My conclusions: if we make SetVirtualAddressMap() optional, we break Windows and NetBSD as they are for sure, and we might take a risk with FreeBSD. The BSDs can probably be fixed, though.

I am inclined to drop this pull request completely now; let's discuss it during our next call.

[xypron]

SetVirtualAddress() goes hand in hand with ConvertPointer(). So the conclusion seems to be that we should keep requiring these. Both services return EFI_UNSUPPORTED after SetVirtualAddress(). SetVirtualAddress() may be called with a 1:1 mapping to switch the services "off".

[vstehle]

Call of Jun 18: drop this