Messages in this thread |  | | From | Jens Wiklander <> | | Date | Mon, 1 Dec 2025 14:06:07 +0100 | | Subject | Re: [PATCH v2 1/1] tee: optee: expose OS revision via sysfs |
| |
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.
Cheers, Jens
|  |