Received-SPF: pass (google.com: domain of linux-kernel+bounces-74701-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <7a7f8f0c1b9d124bfc01b66082abf2d8445564ce.camel@HansenPartnership.com>
Subject: Re: [PATCH 1/3] tpm: protect against locality counter underflow
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko@kernel.org>, Lino Sanfilippo
 <l.sanfilippo@kunbus.com>, Alexander Steffen
 <Alexander.Steffen@infineon.com>,  "Daniel P. Smith"
 <dpsmith@apertussolutions.com>, Jason Gunthorpe <jgg@ziepe.ca>, Sasha Levin
 <sashal@kernel.org>,  linux-integrity@vger.kernel.org,
 linux-kernel@vger.kernel.org
Cc: Ross Philipson <ross.philipson@oracle.com>, Kanth Ghatraju
	 <kanth.ghatraju@oracle.com>, Peter Huewe <peterhuewe@gmx.de>
Date: Wed, 21 Feb 2024 07:37:01 -0500
In-Reply-To: <CZA9GMC718HA.1JFHTTWV563IE@seitikki>
References: <20240131170824.6183-1-dpsmith@apertussolutions.com>
	 <20240131170824.6183-2-dpsmith@apertussolutions.com>
	 <CYU3CFW08DAA.29DJY7SJYPJJZ@suppilovahvero>
	 <2ba9a96e-f93b-48e2-9ca0-48318af7f9b1@kunbus.com>
	 <ae3fecc4-7b76-4607-8749-045e17941923@infineon.com>
	 <91f600ef-867b-4523-89be-1c0ba34f8a4c@kunbus.com>
	 <CZA9CM3PDILC.82JMLUWMB6B7@seitikki> <CZA9GMC718HA.1JFHTTWV563IE@seitikki>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Tue, 2024-02-20 at 22:31 +0000, Jarkko Sakkinen wrote:
> 
> 2. Because localities are not too useful these days given TPM2's
>    policy mechanism

Localitites are useful to the TPM2 policy mechanism.  When we get key
policy in the kernel it will give us a way to create TPM wrapped keys
that can only be unwrapped in the kernel if we run the kernel in a
different locality from userspace (I already have demo patches doing
this).

>  I cannot recall out of top of my head can
>    you have two localities open at same time.

I think there's a misunderstanding about what localities are: they're
effectively an additional platform supplied tag to a command.  Each
command can therefore have one and only one locality.  The TPM doesn't
have a concept of which locality is open; if you look at the reference
implementation, the simulator has a __plat__LocalitySet() function
which places all commands in the just set locality until you change to
a different one.

However, since the way localities are implemented (i.e. what triggers
_plat__LocalitySet()) is implementation defined, each physical TPM
device has a different way of doing the set (for instance, for TIS
TPM's locality is a function of the port set used to address the TPM;
for CRB TPMs it can be an additional tag on the buffer for command
submission).   I think the locality request/relinquish was modelled
after some other HW, but I don't know what.

James