linux-kernel - Re: [PATCH v19 2/6] remoteproc: Add TEE support

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: <aJ2Npmru9RLPTj7c@sumit-X1>
Date: Thu, 14 Aug 2025 12:47:58 +0530
From: Sumit Garg <sumit.garg@...nel.org>
To: Abdellatif El Khlifi <abdellatif.elkhlifi@....com>
Cc: Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-remoteproc@...r.kernel.org, linux-kernel@...r.kernel.org,
	op-tee@...ts.trustedfirmware.org, devicetree@...r.kernel.org,
	Srinivas Kalaga <Srinivas.Kalaga2@....com>
Subject: Re: [PATCH v19 2/6] remoteproc: Add TEE support

Hi Abdellatif,

On Wed, Aug 13, 2025 at 05:42:58PM +0100, Abdellatif El Khlifi wrote:
> Hi Arnaud,
> 
> > Add a remoteproc TEE (Trusted Execution Environment) driver that will be
> > probed by the TEE bus. If the associated Trusted application is supported
> > on the secure part, this driver offers a client interface to load firmware
> > by the secure part.
> > This firmware could be authenticated by the secure trusted application.
> > 
> > A specificity of the implementation is that the firmware has to be
> > authenticated and optionally decrypted to access the resource table.
> > 
> > Consequently, the boot sequence is:
> > 
> > 1) rproc_parse_fw --> rproc_tee_parse_fw
> >    remoteproc TEE:
> >    - Requests the TEE application to authenticate and load the firmware
> >      in the remote processor memories.
> >    - Requests the TEE application for the address of the resource table.
> >    - Creates a copy of the resource table stored in rproc->cached_table.
> > 
> > 2) rproc_load_segments --> rproc_tee_load_fw
> >    remoteproc TEE:
> >    - Requests the TEE application to load the firmware. Nothing is done
> >      at the TEE application as the firmware is already loaded.
> >    - In case of recovery, the TEE application has to reload the firmware.
> > 
> > 3) rproc_tee_get_loaded_rsc_table
> >    remoteproc TEE requests the TEE application for the address of the
> >    resource table.
> > 
> > 4) rproc_start --> rproc_tee_start
> >    - Requests the TEE application to start the remote processor.
> > 
> > The shutdown sequence is:
> > 
> > 5) rproc_stop --> rproc_tee_stop
> >    - Requests the TEE application to stop the remote processor.
> > 
> > 6) rproc_tee_release_fw
> >    This function is used to request the TEE application to perform actions
> >    to return to the initial state on stop or on error during the boot
> >    sequence.
> > 
> > Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>
> ...
> > +
> > +static const struct tee_client_device_id rproc_tee_id_table[] = {
> > +	{UUID_INIT(0x80a4c275, 0x0a47, 0x4905, 0x82, 0x85, 0x14, 0x86, 0xa9, 0x77, 0x1a, 0x08)},
> > +	{}
> > +};
> 
> Other implementations may use different UUIDs.
> What about adding a kernel configuration option which, when enabled, allows
> alternative implementations to override this table?

You don't need any other kernel configuration option for table override
but rather you extend this table with UUID for service provided by
TS-TEE.

> 
> > +/**
> > + * rproc_tee_register() - Register a remote processor controlled by the TEE application.
> ...
> > +
> > +static int rproc_tee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> > +{
> > +	/* Today we support only the OP-TEE, could be extend to other tees */
> > +	return (ver->impl_id == TEE_IMPL_ID_OPTEE);
> > +}
> 
> Could we make ver->impl_id user-configurable please ? for example, by reading
> it from the device tree since it isn’t discoverable at runtime? In our setup, we’d set
> it to TEE_IMPL_ID_TSTEE.

In case the TS-TEE service gets enumerated on TEE bus then the
ver->impl_id will get automatically configured to TEE_IMPL_ID_TSTEE. It
is how the driver will get to know if it is communicating with an OP-TEE
based service of TS-TEE based service.

> 
> > +
> > +static int rproc_tee_probe(struct device *dev)
> > +{
> > +	struct tee_context *tee_ctx;
> > +	int ret;
> > +
> > +	/* Open context with TEE driver */
> > +	tee_ctx = tee_client_open_context(NULL, rproc_tee_ctx_match, NULL, NULL);
> > +	if (IS_ERR(tee_ctx))
> > +		return PTR_ERR(tee_ctx);
> > +
> > +	ret = mutex_lock_interruptible(&ctx_lock);
> > +	if (ret)
> > +		return ret;
> 
> In some TEEs, the client driver might need to perform extra work during probing.
> For example, when using TS TEE, calling tee_shm_alloc_kernel_buf() is required.
> Could we introduce an rproc_tee_ops and add a TEE probe operation called by the
> remoteproc driver for performing custom TEE setup ?

Sure, as I mentioned above the driver will be able to know if it's
communicating with TS-TEE then the additional functionality needed can
be conditionally implemented during probe.

I think it is really the next step after this patch-set lands where we
have to support the remoteproc service hosted under different TEE
implementations like OP-TEE, TS-TEE or QTEE etc.

-Sumit