Re: [PATCH 0/2] efi: Expose the runtime-services workqueue via sysfs

[Ilias Apalodimas]

Hi Sebastian,

On Thu, 12 Feb 2026 at 18:20, Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> On 2026-02-12 09:09:51 [+0200], Ilias Apalodimas wrote:
> > Hi Sebastian,
> Hi Ilias,
>
> > Late to the party but ...
>
> glad to have you.
>
> > On Mon, 9 Feb 2026 at 17:55, Sebastian Andrzej Siewior
> > > What I don't know is if this is a problem, i.e. is it possible to
> > > interrupt the secure monitor and continue in Linux before heading back
> > > to the secure environment or not.
> >
> > In theory yes. In practice, at least for arm & OP-TEE, the
> > communication between the TEE and the secure-world app doing the
> > variable chekcs & authentication is via the MM protocol [0].
> > IIRC that requires to run to completion. So what happens is that you
> > enter OP-TEE and right before the StMM is invoked (the app that
> > handles EFI variables) all exceptions are masked and it must run to
> > completion.
> > The period of masking does not include writing the variables to
> > storage. That's handled differently and is interruptible.
>
> There it RTC and variables which is the most common thing. If you can
> somehow outsource variable read/ write then fine but I guess you need to
> wait somehow to ensure the data is written. Anyway.
>

Yes the variables are processed with exceptions disabled, but the
actual writing to the RPMB runs as OP-TEE RPCs(remote procedure calls)
which can be interrupted.

> That referenced document describes the protocol but not the
> implementation of how communication works. What I found is that most
> interfaces in the TEE world end up either in "SMCCC_1_2 hvc" or
> "SMCCC_1_2 smc". The smc command in terms of arguments is described in
>         https://documentation-service.arm.com/static/5f8ea482f86e16515cdbe3c6
>
> but it does not say if the interrupts are masked.

It's a bit cryptic indeed. It doesn't specifically mandate it, but the
chapter 2 introduction says
"A description of how MM services can be invoked asynchronously is
beyond the scope of this specification". So we tend to keep them
disabled. But as i said I am pretty sure keeping them enabled, if
needed, won't break anything.

> I would assume that it
> transfers the execution control to the secure monitor which is then
> entered with disabled interrupts similar to an exception on the linux
> side. In that case it would mandate a workqueue kind of solution so it
> can be pinned to a CPU.

We enter OP-TEE with exceptions is enabled. It's only when we enter
the S-EL0 application that processes the variables we mask exceptions
[0].

>
> The only exception here seems to be the amdtee driver
> (psp_tee_process_cmd()) which sends a command and waits for an answer.
>
> Sebastian

[0] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/stmm_sp.c#L124

Regards
/Ilias