From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C075128395 for ; Mon, 22 Dec 2025 10:07:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766398052; cv=none; b=bWjZz0iGmUFR0RgoqsnogmvchY5Cf3MymiqIhnU4kcsRpWR6hiVyqFxD6pPQ4lbslFrTV6uwO+IiGtYIcMpVCbbOW3jSnQi6O3zYbZ4b1tAKjeyBhdk1L6KWJlzliz95A6EJ7Yk6UcpoFFcjYpAZ/qe3sN49XQ71Utm3nwDHsi8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766398052; c=relaxed/simple; bh=vR7MvzdDeRVQZr2cC/AFaerrmSj5XSjNB3xtBV9n+QE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C8vSyJokZNhxhDUCDDzZh+QgCFbb2cfnqvIkDuyY2FbcoT6YIG5Jfe/96liHv/ieghQ++AkF65ddnxZj95IAphtxZJyuxDYxC4Q1QN2CHqYfFhfGx+DUfHyb9+R50Tz+8hNrrtDRfwr4HvfVNOQOt6eBv9QzpbMZYHOO08uA2wM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pSSyG/4+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pSSyG/4+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4D504C4CEF1; Mon, 22 Dec 2025 10:07:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1766398051; bh=vR7MvzdDeRVQZr2cC/AFaerrmSj5XSjNB3xtBV9n+QE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pSSyG/4+mke5tzNmdczpYaIJ62ODcF1HypyjcYtqd9jOE93taqoiJn58xXhF75YC9 QQghy295tiNIRhclKCznU4uAm9kLhwhUU/Ig6KFtvIUzLVPwPBVxNVnhJ0bGFKMnnZ DJSmjXxRrxhORLU95iCOmZjjSM94Mq1KOlS+/0PrkbbF6JRuVubuOEtSQBf+XRvS2w peTcH3z60ewBQPf3tkrdR7vhBllqAFV0K+uxUDSBgdd2gsJoh9Z2GGNMx2ivh078fN NqpTmIcLE5Hvs+xSOD8fy/1VjEq4LXahqrNDsG4l0q+74OHKwA9yfbV55amAfoefF6 Oa+rorh6ocsTg== Date: Mon, 22 Dec 2025 15:37:24 +0530 From: Sumit Garg To: Jens Wiklander Cc: Aristo Chen , linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org, harshal.dev@oss.qualcomm.com, Aristo Chen , mario.limonciello@amd.com, Rijo Thomas , Amirreza Zarrabi Subject: Re: [PATCH v2 1/1] tee: optee: expose OS revision via sysfs Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 wrote: > > > > Hi Jens > > > > Jens Wiklander 於 2025年12月9日週二 下午4:31寫道： > > > > > > Hi Aristo, > > > > > > On Sun, Dec 7, 2025 at 3:01 PM Aristo Chen wrote: > > > > > > > > Hi Jens, > > > > > > > > Jens Wiklander 於 2025年12月3日週三 下午3:51寫道： > > > > > > > > > > Hi, > > > > > > > > > > On Tue, Dec 2, 2025 at 10:54 AM Aristo Chen wrote: > > > > > > > > > > > > Hi Jens > > > > > > > > > > > > Jens Wiklander 於 2025年12月1日週一 下午9:06寫道： > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Dec 1, 2025 at 12:48 PM Aristo Chen wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Sumit Garg 於 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 wrote: > > > > > > > > > > > > > > > > > > > > > > > > From: Aristo Chen > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > --- > > > > > > > > > > > > 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. -Sumit