public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rapeli <mikko.rapeli@linaro.org>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Jerome Forissier <jerome.forissier@linaro.org>,
	linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	op-tee@lists.trustedfirmware.org,
	Shyam Saini <shyamsaini@linux.microsoft.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Sumit Garg <sumit.garg@linaro.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Manuel Traut <manut@mecka.net>
Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem
Date: Tue, 28 May 2024 12:30:48 +0300	[thread overview]
Message-ID: <ZlWkSCCjJ2fbE2ML@nuoska> (raw)
In-Reply-To: <CAHUa44G0bcK55RxNrN5sXiicBZ-BJtA46KpedfBdUSKsN8eUOA@mail.gmail.com>

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@linaro.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@linaro.org>
> > > Tested-by: Manuel Traut <manut@mecka.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

  reply	other threads:[~2024-05-28  9:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-27 12:13 [PATCH v7 0/4] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
2024-05-27 12:13 ` [PATCH v7 1/4] rpmb: add " Jens Wiklander
2024-05-27 12:13 ` [PATCH v7 2/4] mmc: block: register RPMB partition with the RPMB subsystem Jens Wiklander
2024-05-29  7:39   ` Linus Walleij
2024-05-27 12:13 ` [PATCH v7 3/4] tee: add tee_device_set_dev_groups() Jens Wiklander
2024-05-27 12:13 ` [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem Jens Wiklander
2024-05-27 13:00   ` Jerome Forissier
2024-05-27 13:24     ` Jens Wiklander
2024-05-28  9:30       ` Mikko Rapeli [this message]
2024-05-29  5:26         ` Sumit Garg
2024-05-29  7:09           ` Mikko Rapeli
2024-05-29  8:06             ` Sumit Garg
2024-05-29  8:18               ` Sumit Garg
2024-05-29  9:38             ` Manuel Traut
2024-05-29 14:26               ` Mikko Rapeli
2024-05-30  7:35                 ` Manuel Traut
2024-05-30  8:29                   ` Mikko Rapeli
2024-05-30 14:22                     ` Manuel Traut
2024-05-27 14:38   ` Sumit Garg
2024-05-28  9:08     ` Jens Wiklander
2024-05-29  5:04       ` Sumit Garg
2024-06-03  9:10   ` Manuel Traut
2024-06-10 12:52     ` Jens Wiklander
2024-06-11  3:02       ` Mikko Rapeli
2024-06-11 10:43         ` Sumit Garg
2024-06-12  1:14           ` Mikko Rapeli
2024-06-12  6:56             ` Jens Wiklander
2024-05-30 14:38 ` [PATCH v7 0/4] Replay Protected Memory Block (RPMB) subsystem Manuel Traut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZlWkSCCjJ2fbE2ML@nuoska \
    --to=mikko.rapeli@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bvanassche@acm.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jens.wiklander@linaro.org \
    --cc=jerome.forissier@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=manut@mecka.net \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=rdunlap@infradead.org \
    --cc=shyamsaini@linux.microsoft.com \
    --cc=sumit.garg@linaro.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox