linux-kernel - Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZlWkSCCjJ2fbE2ML@nuoska>
Date: Tue, 28 May 2024 12:30:48 +0300
From: Mikko Rapeli <mikko.rapeli@...aro.org>
To: Jens Wiklander <jens.wiklander@...aro.org>
Cc: Jerome Forissier <jerome.forissier@...aro.org>,
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
	op-tee@...ts.trustedfirmware.org,
	Shyam Saini <shyamsaini@...ux.microsoft.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Sumit Garg <sumit.garg@...aro.org>,
	Ilias Apalodimas <ilias.apalodimas@...aro.org>,
	Bart Van Assche <bvanassche@....org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Manuel Traut <manut@...ka.net>
Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> <jerome.forissier@...aro.org> wrote:
> >
> > On 5/27/24 14:13, Jens Wiklander wrote:
> > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > available.
> > >
> > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > devices until one is found with the expected RPMB key already
> > > programmed.
> > >
> > > Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>
> > > Tested-by: Manuel Traut <manut@...ka.net>
> > > ---
> > >  Documentation/ABI/testing/sysfs-class-tee |  15 ++
> > >  MAINTAINERS                               |   1 +
> > >  drivers/tee/optee/core.c                  |  96 +++++++++++-
> > >  drivers/tee/optee/device.c                |   7 +
> > >  drivers/tee/optee/ffa_abi.c               |  14 ++
> > >  drivers/tee/optee/optee_ffa.h             |   2 +
> > >  drivers/tee/optee/optee_private.h         |  26 +++-
> > >  drivers/tee/optee/optee_rpc_cmd.h         |  35 +++++
> > >  drivers/tee/optee/optee_smc.h             |   2 +
> > >  drivers/tee/optee/rpc.c                   | 177 ++++++++++++++++++++++
> > >  drivers/tee/optee/smc_abi.c               |  14 ++
> > >  11 files changed, 387 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > new file mode 100644
> > > index 000000000000..c9144d16003e
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > @@ -0,0 +1,15 @@
> > > +What:                /sys/class/tee/tee{,priv}X/rpmb_routing_model
> >
> > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
> 
> Doesn't the routing model concern tee-supplicant more than a TEE
> client? Then it might make more sense to have
> /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> devices representing the same internal struct optee makes it easier to
> find. Anyway, I don't mind removing one. Mikko, what do you prefer?

As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
could be the needed indicator for userspace to queue tee-supplicant startup.

Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
currently requires tee-supplicant to be started. Detecting the existence of TPM before
kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.

In userspace and systemd it's just important to know that service need to wait for a TPM2
device to appear in early initrd and when can things be postponed to main rootfs and later
stages. Kernel and udev will bring up the device then once discovered.
Knowledge about the RPMB backend is important when something like TPM2 device
depends on it.

Hope this helps,

-Mikko