Received: by 2002:a05:6500:1b8f:b0:1fa:5c73:8e2d with SMTP id df15csp520244lqb; Wed, 29 May 2024 02:55:22 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXrwmqHFcuv4CXwwJIne1D+27LK3nzDLDqGHTGqyuFmo+aZGyFr0C87wSj2oz8tF0TjKmQTlsSwPVeEjuFlM2oxQ8jX4+UrW6RNSUPS2g== X-Google-Smtp-Source: AGHT+IGCjA3Htmjg/OC+Gvaf9jgnfkBT40+mqNmPwYRbcHt7tXvFyw/es6jnmohlkz3F/rJXJY3b X-Received: by 2002:a17:90a:6786:b0:2bf:ee29:1a64 with SMTP id 98e67ed59e1d1-2bfee292f7bmr6393666a91.23.1716976522149; Wed, 29 May 2024 02:55:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716976522; cv=pass; d=google.com; s=arc-20160816; b=AUQPlW9jQ3dsJ0sQlv6s8oR/5RXeGIyZ7R/4BCCj+xPr9a2M2VfkQrz/uUi2C8C/UT 1UkLncS4wDg9Z7+ZY4z4ICQHUx7bLDzICuY0fdZX7l9KnZfvUNYv+XvYok/0GOF7ICNo OXcjEX0SGishAwIT0z6JJT/Xozs4SYqRIp7UVhgCmVj8NMKfyokg4rf0UmL3+MPHb13j hB4yALuO8p8Vd1Qc8ps3uLeezjKejqfL6HsO7N405IX18KSMHH1iPkMLrSbliIQsDFAI esk5UdhKFp4rbXjWswwez26g1P5ic02WJBbuNUrMAVtvCYViWFlAswTtXK9aD6JqTnVu dgtw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=qih+HLGUWvoH2jVT35xEW3TJMpWo9+n5jaoJ0q8gPzA=; fh=qipK4wioLKnqlmbh+9FTnQLbjgIyPRUyLOOsOL61r38=; b=kic462cWoMMq4t0QUiwAWBZtxAXBgJj9IIhMUpXKNw4XOkE4g7+FvXr00t6HheUYNl jyikGr559xS9m7nZ9PkI+y6Gb+evVfwTfvz+7dGxOwm4CZThGp6UtMiSqGFiT/Kx78pt Xs2Jo7LF+nP5FJv4vrooX56RQIPn6GPXOlTYkBfZQNCLbKehd+qpf2iD+wlXUNlUD7DX n50JDsUwCFxtvQMES+Ad4HZ/fsYyp30KdpmrRiixiWxcG77bQl8eXosw4ORlT6MyfEMf yY58Nu4yitd032uIvEz7JIh5ZeG3XYAmAn1J58oVsDF5LKUbnd9/BsLjB8ftfTEYMpuf VZtg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=temperror (no key for signature) header.i=@mecka.net header.s=2016.11 header.b=nnHXk6+4; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-193853-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-193853-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id 98e67ed59e1d1-2bf5fe623ddsi9661956a91.162.2024.05.29.02.55.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 02:55:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-193853-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@mecka.net header.s=2016.11 header.b=nnHXk6+4; arc=pass (i=1); spf=pass (google.com: domain of linux-kernel+bounces-193853-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-193853-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 0AF96B2427C for ; Wed, 29 May 2024 09:38:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B1BEE16A37D; Wed, 29 May 2024 09:38:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=mecka.net header.i=@mecka.net header.b="nnHXk6+4" Received: from mecka.net (mecka.net [159.69.159.214]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2B42E33CFC; Wed, 29 May 2024 09:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.159.214 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716975497; cv=none; b=ibWB22FqfxNAvyUhe4PlqfONHkt5Ogmv9u1A5Eg1e6AusZnkqSt2EtS87D0/KLEl/zIZnLNY4LhvWiIJjOdGUkVZtXkh1XRnDbSyNF3UG6YNIQ0gM+71yoAMB3d99E+sx6v7SR4T5g2Ei8b68HMIMUXyIjub1rjbwjd+ZPeNNiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716975497; c=relaxed/simple; bh=t+NQR7JOcisqSyTIuHhXwptMXLRRcGVKKGvUmnuaQ3Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U7ANcDfFImX1Sa5FKs13GJMzfxDssDGrpUlrbv1ILr/KCMd2DPqEfJIXnBoMuc9XcRJRjmnOiEJv8+yj0mDTTAGARKZQdkIJiiQyySih6bkMStFL9kIBZnLxuyDtPeQRFkq/cFlCrp4QHScqSZF7OqYXxwv8UTk7Y8bH3rXqFBc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=mecka.net; spf=none smtp.mailfrom=manut.de; dkim=fail (0-bit key) header.d=mecka.net header.i=@mecka.net header.b=nnHXk6+4 reason="key not found in DNS"; arc=none smtp.client-ip=159.69.159.214 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=mecka.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=manut.de DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mecka.net; s=2016.11; t=1716975486; bh=t+NQR7JOcisqSyTIuHhXwptMXLRRcGVKKGvUmnuaQ3Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=nnHXk6+4jIfPypE13CpuQyuw5ZPGU7X9fw4pi7s3T40N3XMIHGCTSzseD2yT0pXyc l54m3gG9GGIDTttXaFKWomH1jCFkfE3N1L1p93+HJPPdZcHP/vLv8lOvfXVikt9iUi KDX/VMZ0uhvICNpm+Dq5pAkmwG3PwRdTitFF9aIEKKFJoShxLbsDw8tIarY+Bxp2m6 vtW1fc53KZlGnhOGH2GbSszYAb1tgNGVocGsy/Qrula++sTb1rBWe8HXPyIiFjCwTK +iLMMn/S7RH7nnmJmWB3vNDo0gvYKOaG6ZVTiAwN6Vq+uCGJmeiZLxxlluac+O0Dq5 c2ArOze6Nr+Qw== Received: by mecka.net (Postfix, from userid 1000) id B31E250B258; Wed, 29 May 2024 11:38:06 +0200 (CEST) Date: Wed, 29 May 2024 11:38:06 +0200 From: Manuel Traut To: Mikko Rapeli Cc: Sumit Garg , Jens Wiklander , Jerome Forissier , linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, op-tee@lists.trustedfirmware.org, Shyam Saini , Ulf Hansson , Linus Walleij , Ilias Apalodimas , Bart Van Assche , Randy Dunlap , Ard Biesheuvel , Arnd Bergmann , Greg Kroah-Hartman Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem Message-ID: References: <20240527121340.3931987-1-jens.wiklander@linaro.org> <20240527121340.3931987-5-jens.wiklander@linaro.org> 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: 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 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 > > > > 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. 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 Manuel