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
>
>
> >> 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.
