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] [day] [month] [year] [list]
Message-ID: <CAHUa44HUFPy24wZrA03z0KHZqUmbT+dSP+7zOT-zrrFq_-h8mg@mail.gmail.com>
Date: Mon, 1 Dec 2025 14:06:07 +0100
From: Jens Wiklander <jens.wiklander@...aro.org>
To: Aristo Chen <jj251510319013@...il.com>
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,

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.

Cheers,
Jens

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ