On Mon, 6 Feb 2023 at 20:12, Sumit Garg sumit.garg@linaro.org wrote:
Thanks Ard for the detailed background information.
On Mon, 6 Feb 2023 at 14:52, Ard Biesheuvel ardb@kernel.org wrote:
On Mon, 6 Feb 2023 at 07:44, Sumit Garg sumit.garg@linaro.org wrote:
On Fri, 3 Feb 2023 at 16:25, Jens Wiklander jens.wiklander@linaro.org wrote:
..
StMM uses the MM protocol. It was originially using raw SMCs as a conduit, but with the need for OP-TEE accessing RPMB that's not usable. So instead we use OP-TEE MSG as a conduit. Seen from that perspective we're only resuing something established instead of inventing something new.
Aren't we already adding PTA_STMM?
Isn't the StMM specific to Arm as you already mentioned it was designed to specifically use raw SMCs? So if in future AMD TEE wants to implement EFI services, can we suggest they reuse the MM interface?
I am not sure why we need to redirect EFI variables via MM interface communication buffers rather than directly using the TEE shared memory approach.
Ard,
Since you have better insights into how EFI runtime services have to be implemented, can you share your opinion here? It may be something I am missing here.
Hello Sumit,
I'm not sure I understand what you are asking me here. Allow me to reiterate, apologies if I am stating the obvious:
The EFI spec describes how the OS should expose the EFI runtime services, but this is difficult to implement when access to the underlying storage requires arbitration between accesses by the OS itself and accesses made by the firmware.
Agree.
On systems where this issue is absent, the EFI runtime service implementation for the variable services are very thin wrappers around calls into standalone MM, which are not standardized, but are also not ARM specific (standalone MM is being used on other architectures as well, and 'classic' SMM uses the same protocol but dispatches the call into the secure/SMM world in a different way)
Thanks for the clarification. So wouldn't it be better to have the standalone MM API reside here: drivers/firmware/efi/ and it should be exposed instead of efivars ops? As you mention below that there is nothing OP-TEE specific in there.
On systems where arbitration is needed, the standalone MM payload needs to call back up into the OS to request access to the flash storage. OP-TEE is a suitable vehicle for this, as it already does the same thing for other reasons, and is already set up to dispatch SMC calls that are taken to S-EL1.
Agree.
All of his is uncharted territory as far as the EFI spec is concerned, as it occurs inside the StMM pseudo-API call, which itself normally occurs inside the EFI runtime service call. Given that we cannot use the latter (as the firmware does not provide a working get/setvariable at OS runtime [0]), we need to provide some plumbing to call the StMM pseudo-API directly, and expose it as an alternative efivars implementation. (Note that this should mean that other implementations of the StMM pseudo-API that do not require this arbitration may potentially be accessed in the same way, although I don't see a reason to use it like that.)
If I am understanding you correctly, your question is whether OP-TEE should expose the StMM pseudo-API in the usual way as well, and make the OS rely on the usual discovery mechanisms etc to bind to it?
No, I am trying to understand and generalize how an EFI runtime service ABI would look like among Linux kernel and a TEE. As you may be aware there are multiple TEE implementations and OP-TEE is one of them. So we should try to have a generic TEE client driver [1] rather than every other TEE implementation coming up with its own driver.
If that is indeed your question: what purpose would that serve, exactly?
In principle, the OS piece that implements efivars on top of the StMM pseudo-API should not be specific to any TEE implementation or API, and I think the fact that OP-TEE is the provider in this case is an implementation detail.
Yeah as I said above we should abstract the StMM pieces out of an OP-TEE driver and then the driver can be a generic TEE client driver which is just providing the underline vehicle (invoke commands and StMM buffer passing) as you described above.
If you feel that OP-TEE should not expose this interface directly to begin with, and rely on some marshalling layer to expose the StMM pseudo-API on top of its ordinary exposed API, that is really an OP-TEE internal matter (which I think is what you discussed with Jens up in the thread?) Since StMM calls are defined in terms of SMC instructions + arguments, this would require more code inside OP-TEE to translate access to an API that it already exposes directly as well, so I'm not sure what the gain would be.
No I am not against OP-TEE exposing StMM stuff but rather the StMM stuff (buffer allocation etc.) being bundled into OP-TEE client driver.
The thing to remember is that, even though the wrappers are very thin, it is fundamentally the StMM API that is being exposed, not the EFI runtime services API, and so whether or not a use case may materialize that wants to expose a different API via efivars is out of scope here, even if they are roughly shaped like get/setvariable.
Okay I get your point. If we want the StMM API to be exposed then I think the EFI subsystem is the suitable place for that.
Thank you for your comments. In the next version, I move the StMM code under drivers/firmware/efi/stmm, then 'optee' prefix is changed to 'tee' because StMM code does not contain OP-TEE specific code.
Regards, Masahisa Kojima
[1] Although there can be minor differences allowed based on TEE implementation ID. You can consider it analogous to how we use multiple DT compatibles for a generic platform driver.
-Sumit