On 09/10/2026 12:15, Ilias Apalodimas wrote: > On Fri, 9 Oct 2026 at 14:08, Harsimran Singh Tungal > <[email protected]> wrote: >> >> >> >> On 09/10/2026 09:19, Ilias Apalodimas wrote: >>> [...] >>> >>>>>>>> /** >>>>>>>> @@ -1129,7 +1262,7 @@ void efi_variables_boot_exit_notify(void) >>>>>>>> efi_runtime_services.get_variable = efi_get_variable_runtime; >>>>>>>> efi_runtime_services.get_next_variable_name = >>>>>>>> efi_get_next_variable_name_runtime; >>>>>>> >>>>>>> >>>>>>> All the get_variable*() calls used to point to the function from >>>>>>> efi_var_common.c. >>>>>>> By changing this you are breaking the runtime case for OP-TEE since now >>>>>>> we will get >>>>>>> EFI_OUT_OF_RESOURCES. >>>>>>> There's no easy way to fix this at runtime. For OP-TEE the kernel might >>>>>>> replace this call >>>>>>> with an internal OP-TEE call if it's part of the firmware and announces >>>>>>> it can provide >>>>>>> EFI runtime services. However, the default uuse case, which we don't >>>>>>> support SetVariable >>>>>>> at runtime only needs to keep working. >>>>>>> >>>>>>> I'll post a script next week so you can replicate and test this in QEMU >>>>>>> with OP-TEE etc. >>>>>>> >>>>>>> Cheers >>>>>>> /Ilias >>>>>>> >>>>>> Hi Ilias, >>>>>> Can you please share the script, so that I can replicate and test this >>>>>> in QEMU with OP-TEE? >>>>> >>>>> https://github.com/apalos/efi_optee_variables >>>>> >>>>> make run-fip should give you a QEMU command line. You just have to add >>>>> an OS image to test. >>>>> >>>>> Cheers >>>>> /Ilias >>>>>> >>>> >>>> Hi Ilias, >>>> >>>> Thank you for sharing the repository and instructions. >>>> I tried the OP-TEE/non-FF-A QEMU setup from your repository and it >>>> exposed a regression in my current series. >>>> >>>> With CONFIG_EFI_MM_COMM_TEE=y and CONFIG_ARM_FFA_RT_MODE=n, Linux hit >>>> an EFI runtime paging fault when booted through U-Boot EFI. The reason >>>> was that TEE ExitBootServices() path only installed runtime variable >>>> callbacks inside the CONFIG_ARM_FFA_RT_MODE path. That kept the FF-A >>>> case working, but it accidentally stopped the non-FF-A OP-TEE case from >>>> switching to the existing cached-variable runtime callbacks. >>>> >>>> I tested a fix by keeping the FF-A/MM runtime callbacks only for >>>> CONFIG_ARM_FFA_RT_MODE=y, and using the common cached-variable runtime >>>> callbacks when CONFIG_ARM_FFA_RT_MODE=n. To make that clean, I plan to >>>> add a small separate commit which moves the common runtime >>>> QueryVariableInfo() and SetVariable() helpers, plus their shared >>>> SetVariable() validation helper, from efi_variable.c into >>>> efi_var_common.c. >>> >>> I am not sure I understand the plan. efi_var_common.c already has >>> callback for the above, it calls the _int variable for each service. >>> >>> Thanks >>> /Ilias >> >> Hi Ilias, >> Thanks, I rechecked the pre-FF-A runtime TEE code and I understand the >> confusion now. >> >> >> >> >> >> >> >> Before the FF-A runtime changes, efi_variable_tee.c already had local >> runtime callbacks for QueryVariableInfo() and SetVariable(), and both >> returned EFI_UNSUPPORTED as follows: >> >> static efi_status_t __efi_runtime EFIAPI >> efi_query_variable_info_runtime(u32 attributes, >> u64 *max_variable_storage_size, >> u64 *remain_variable_storage_size, >> u64 *max_variable_size) >> { >> return EFI_UNSUPPORTED; >> } >> >> static efi_status_t __efi_runtime EFIAPI >> efi_set_variable_runtime(u16 *variable_name, >> const efi_guid_t *guid, >> u32 attributes, efi_uintn_t data_size, >> const void *data) >> { >> return EFI_UNSUPPORTED; >> } >> >> The common callbacks from efi_var_common.c covered GetVariable() and >> GetNextVariableName(). >> >> The regression was introduced because this series only installed and >> renamed the TEE runtime callbacks when CONFIG_ARM_FFA_RT_MODE was >> enabled. That made the FF-A case work, but it skipped the previous >> OP-TEE/non-FF-A runtime callback setup. >> >> I am planning to restore the pre-FF-A TEE behavior when >> CONFIG_ARM_FFA_RT_MODE=n, and only switch to the new MM/FF-A callbacks >> when CONFIG_ARM_FFA_RT_MODE=y. The relevant part now looks like below >> along redefining efi_query_variable_info_runtime() and >> efi_set_variable_runtime() as before in efi_variable_tee.c returning >> EFI_UNSUPPORTED: >> >> if (IS_ENABLED(CONFIG_ARM_FFA_RT_MODE)) { >> efi_runtime_services.query_variable_info = >> efi_query_variable_info_int_runtime; > > Don't name these _int. Maybe efi_query_variable_info_ffa_runtime? > >> efi_runtime_services.get_variable = >> efi_get_variable_int_runtime; >> efi_runtime_services.get_next_variable_name = >> efi_get_next_variable_name_int_runtime; >> efi_runtime_services.set_variable = >> efi_set_variable_int_runtime; >> } else { >> efi_runtime_services.query_variable_info = >> efi_query_variable_info_runtime; >> efi_runtime_services.get_variable = efi_get_variable_runtime; >> efi_runtime_services.get_next_variable_name = >> efi_get_next_variable_name_runtime; >> efi_runtime_services.set_variable = efi_set_variable_runtime; >> } >> efi_update_table_header_crc32(&efi_runtime_services.hdr); >> >> With this, the OP-TEE/non-FF-A case uses the same callbacks as before >> the FF-A runtime changes. I tested it with your QEMU OP-TEE setup and it >> looks fine to me. >> >> Does this approach make sense to you? > > Yes that's why I thought moving function to the 'common' backend didnt > make any sense. This looks reasonable >
Hi Ilias, I have implemented and tested the changes discussed here. For CONFIG_ARM_FFA_RT_MODE=n, the TEE backend now keeps the pre-FF-A runtime callbacks. For CONFIG_ARM_FFA_RT_MODE=y, it switches to the new FF-A runtime callbacks, now named with the _ffa_runtime suffix. I tested the OP-TEE/non-FF-A QEMU setup from your repository and it looks fine to me. Do you have any further comments, or should I send v6 for review? Regards Harsimran Singh Tungal >> >> >>>> Then, efi_variable_tee.c can select either the common >>>> cached-variable runtime handlers for OP-TEE/non-FF-A, or the new MM/FF-A >>>> runtime handlers for FF-A runtime mode. >>>> >>>> With that change, the same QEMU setup boots Linux through bootefi and a >>>> small initramfs, /sys/firmware/efi is present, and efivarfs mounts >>>> successfully. >>>> >>>> Does this direction look reasonable to you? >>>> >>>> Regards, >>>> Harsimran Singh Tungal >>>>>> Thanks >>>>>> Harsimran Singh Tungal >>>>>>>> - efi_runtime_services.set_variable = efi_set_variable_runtime; >>>>>>>> + efi_runtime_services.set_variable = efi_set_variable_int_runtime; >>>>>>>> efi_update_table_header_crc32(&efi_runtime_services.hdr); >>>>>>>> >>>>>>>> /* Record that ExitBootServices() has been called */ >>>>>>> >>>>>> >>>>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>>>> confidential and may also be privileged. If you are not the intended >>>>>> recipient, please notify the sender immediately and do not disclose the >>>>>> contents to any other person, use it for any purpose, or store or copy >>>>>> the information in any medium. Thank you. >>>> >>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>> confidential and may also be privileged. If you are not the intended >>>> recipient, please notify the sender immediately and do not disclose the >>>> contents to any other person, use it for any purpose, or store or copy the >>>> information in any medium. Thank you. >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
