linux-kernel - Re: [PATCH v2 1/1] tee: optee: expose OS revision via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJwFiGLRVZyr7Hb3PtGyA319hCYEJh9t8XY_amyjhUgqnrZycQ@mail.gmail.com>
Date: Tue, 2 Dec 2025 17:54:02 +0800
From: Aristo Chen <jj251510319013@...il.com>
To: Jens Wiklander <jens.wiklander@...aro.org>
Cc: Sumit Garg <sumit.garg@...nel.org>, linux-kernel@...r.kernel.org, 
	op-tee@...ts.trustedfirmware.org, harshal.dev@....qualcomm.com, 
	Aristo Chen <aristo.chen@...onical.com>, mario.limonciello@....com, 
	Rijo Thomas <Rijo-john.Thomas@....com>, 
	Amirreza Zarrabi <amirreza.zarrabi@....qualcomm.com>
Subject: Re: [PATCH v2 1/1] tee: optee: expose OS revision via sysfs

Hi Jens

Jens Wiklander <jens.wiklander@...aro.org> 於 2025年12月1日週一 下午9:06寫道：
>
> Hi,
>
> On Mon, Dec 1, 2025 at 12:48 PM Aristo Chen <jj251510319013@...il.com> wrote:
> >
> > Hi,
> >
> > Sumit Garg <sumit.garg@...nel.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@...il.com> wrote:
> > > > > >
> > > > > > From: Aristo Chen <aristo.chen@...onical.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@...onical.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.
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.

Thanks,
Aristo
>
> Cheers,
> Jens