Hi Jens and Sumit,
On Mon, Dec 22, 2025 at 6:07 PM Sumit Garg sumit.garg@kernel.org wrote:
On Mon, Dec 22, 2025 at 09:34:24AM +0100, Jens Wiklander wrote:
Hi Aristo,
On Fri, Dec 19, 2025 at 4:39 PM Aristo Chen jj251510319013@gmail.com
wrote:
Hi Jens
Jens Wiklander jens.wiklander@linaro.org 於 2025年12月9日週二 下午4:31寫道：
Hi Aristo,
On Sun, Dec 7, 2025 at 3:01 PM Aristo Chen jj251510319013@gmail.com
wrote:
Hi Jens,
Jens Wiklander jens.wiklander@linaro.org 於 2025年12月3日週三
下午3:51寫道：
Hi,
On Tue, Dec 2, 2025 at 10:54 AM Aristo Chen <
jj251510319013@gmail.com> wrote:
> > Hi Jens > > Jens Wiklander jens.wiklander@linaro.org 於 2025年12月1日週一
下午9:06寫道：
> > > > Hi, > > > > On Mon, Dec 1, 2025 at 12:48 PM Aristo Chen <
jj251510319013@gmail.com> wrote:
> > > > > > Hi, > > > > > > Sumit Garg sumit.garg@kernel.org 於 2025年11月25日週二
下午3:55寫道：
> > > > > > > > On Tue, Nov 25, 2025 at 01:23:22PM +0530, Sumit Garg via
OP-TEE wrote:
> > > > > On Mon, Nov 24, 2025 at 08:15:04AM +0100, Jens
Wiklander wrote:
> > > > > > Hi, > > > > > > > > > > > > On Sat, Nov 22, 2025 at 4:00 PM Wei Ming Chen <
jj251510319013@gmail.com> wrote:
> > > > > > > > > > > > > > From: Aristo Chen aristo.chen@canonical.com > > > > > > > > > > > > > > Today the only way to read the OP-TEE OS version
is from dmesg/journal
> > > > > > > logs, which can be lost as buffers roll over.
Capture the OS revision
> > > > > > > (major/minor/build_id) from secure world for both
SMC and FF-A ABIs, store
> > > > > > > it in the OP-TEE driver, and expose a stable
userspace readout via
> > > > > > > /sys/class/tee/tee*/optee_os_revision. > > > > > > > > > > > > > > Signed-off-by: Aristo Chen <
aristo.chen@canonical.com>
> > > > > > > --- > > > > > > > drivers/tee/optee/core.c | 19
+++++++++++++++++++
> > > > > > > drivers/tee/optee/ffa_abi.c | 13
+++++++++++--
> > > > > > > drivers/tee/optee/optee_private.h | 17
+++++++++++++++++
> > > > > > > drivers/tee/optee/smc_abi.c | 13
+++++++++++--
> > > > > > > 4 files changed, 58 insertions(+), 4 deletions(-) > > > > > > > > > > > > This appears to be a feature that could be useful
for all TEEs.
> > > > > > > > > > True, it is something that TEE core should support.
Although I would
> > > > > have preferred to extend TEE_IOC_VERSION since that's
the common way the
> > > > > user-space library get's TEE implementation specific
information. But
> > > > > since it being already a user-space ABI which doesn't
offer extension.
> > > > > Maybe we can consider adding TEE_IOC_REVERSION instead
of sysfs.
> > > > > > > > Ah, typo here: > > > > > > > > s/TEE_IOC_REVERSION/TEE_IOC_REVISION/ > > > > > > > > -Sumit > > > > > > > > > > > > > > But before doing that we need to know who is the
actual consumer here
> > > > > from user-space perspective? Will the client
applications also depend on
> > > > > the TEE implementation revision? > > > My current thinking is that if the TEE revision is
exposed, users can write a
> > > script to capture the platform state and record the exact
secure OS revision
> > > even after the dmesg/journalctl logs have rolled over.
This would significantly
> > > improve bug triage and regression tracking. > > > > > > In my case, I have a package with precompiled xtest
binaries for multiple
> > > releases (from 3.14 to 4.6), and I work with different
platforms that run
> > > different OP-TEE OS versions. Having a reliable way to
obtain the TEE
> > > revision would help a lot, as it would allow me to select
the correct xtest
> > > version when running tests. > > > > I'm concerned that the ABI might be misused to be part of
what the
> > client expects from the TEE. You even express that as a use
case. I'd
> > rather fix the problem with xtest. > > Thanks for the feedback! To clarify: currently, the OP-TEE OS
revision
> I expose in > sysfs is the same value already printed in dmesg at boot > (e.g., “optee: revision 4.8 (XXXXXX)”). > > Are your concerns specifically about clients inferring
capabilities
> from a revision > string (“rev X.Y implies feature Z”)? If so, I agree that’s
fragile
> and not the intent.
Yes
Thanks for clarifying the concern!
> I’m happy to add a short note in the doc that this is
informational
> only and that > feature detection must use proper capability queries. > > Please let me know if that addresses the worry, or if there’s
another
> concern I’m > missing.
Adding APIs that aren't supposed to be used seems odd. Do you
know if
there are examples in the kernel for this kind of thing?
I’ve done some research and, as far as I can tell, the TEE core
already
provides an informational-only file at
/sys/class/tee/tee0/implementation_id.
My understanding is that it was introduced roughly 10 years ago.
However,
I haven’t found any documentation clarifying its intended purpose,
so I’m
assuming this may be a similar situation. I’d appreciate it if you
could correct
me if I’m wrong.
That one is for a quick way for a client to tell the different TEE device implementations apart. You're right, it resembles your case, except that this is part of a well-defined ABI.
Also, here are some files with similiar purposes:
- /sys/devices/system/cpu/cpu*/microcode/version
/sys/devices/virtual/dmi/id/{bios_date,bios_release,bios_vendor,bios_version}
- /sys/kernel/security/apparmor/revision
Thanks, this is good background information.
We have a BoF session on the TEE subsystem at LPC on Friday [1].
We'll
take the opportunity to discuss it there.
Just a quick follow-up on this patch, has there been any decision or direction from that discussion? I’m happy to rework the patch in whatever direction the group prefers.
No one was against it. We didn't discuss the details, but here's what I'd like to see:
- The callback name should be get_tee_revision() or get_tee_fw_version()
- The FW version is returned as a string for flexibility
- A note that the FW version is not intended to be used to determine
what features, etc, are available, TEE_IOC_VERSION should cover that.
Sumit, what do you think?
That sounds reasonable to me.
Thanks for the feedback! I will prepare V3 patch
-Sumit
Best regards, Aristo