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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZlgsLibqO59kNQUE@mecka.net>
Date: Thu, 30 May 2024 09:35:10 +0200
From: Manuel Traut <manut@...ka.net>
To: Mikko Rapeli <mikko.rapeli@...aro.org>
Cc: Sumit Garg <sumit.garg@...aro.org>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	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>,
	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>
Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Mikko,

On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote:
> Hi,
> 
> On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote:
> > Hi Mikko,
> > 
> > On 10:09 Wed 29 May     , Mikko Rapeli wrote:
> > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <mikko.rapeli@...aro.org> wrote:
> > > > > 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:
> > > > > 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.
> > > > 
> > > > One thing I am trying to find an answer about is why do we need to
> > > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > > As per your example below, the motivation here seems to be the TPM2
> > > > device dependent on RPMB backend but what if other future systemd
> > > > services come up and depend on other services offered by
> > > > tee-supplicant?
> > > 
> > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > > tee-supplicant in userspace and kernel TA drivers like fTPM.
> > > 
> > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> > > 
> > > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> > > 
> > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > > fTPM can not be used due to the tee-supplicant userspace dependency.
> > 
> > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
> > implemented in u-boot so it can already write PCR registers.
> 
> Is build in TA same as early TA? I presume so.

Indeed.. sorry for using the wrong term.

> > With this series and the required changes in OP-TEE and a compiled in fTPM
> > kernel driver and systemd v256 it is possible to use the fTPM in the initrd
> > without tee-supplicant.
> > 
> > Maybe this information is helpful to you, regards
> 
> This is very interesting and I'm trying to get to the same state, though with
> fTPM kernel driver as module. With v6 of this patch set and matching optee changes
> I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver
> due to failing RPC allocation, which tee-supplicant was setting up in the whole chain.
> I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y.

I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also
work with fTPM as kernel module if you use systemd in the initrd
with the new tpm.target in systemd v256.

Regards
Manuel