[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0d925d801d8988bb55afa476fb0564b052d54e62.camel@HansenPartnership.com>
Date: Wed, 22 May 2024 10:20:50 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, Vitor Soares <ivitro@...il.com>,
linux-integrity@...r.kernel.org
Cc: keyrings@...r.kernel.org, Peter Huewe <peterhuewe@....de>, Jason
Gunthorpe <jgg@...pe.ca>, Mimi Zohar <zohar@...ux.ibm.com>, David Howells
<dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, James Morris
<jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 1/3] tpm: Disable TCG_TPM2_HMAC by default
On Wed, 2024-05-22 at 17:11 +0300, Jarkko Sakkinen wrote:
> For tpm_crb we should actually disable HMAC at some point. It is
> essentially a performance regression for it.
You'd think that, because of the shared buffer and no bus, but you
never quite know. For instance several confidential computing early
implementations used the crb interface set up by qemu (i.e. over shared
buffers which are readable by the host). For them the only way to get
security is with sessions. Even with the default Intel CRB, the TPM
transaction isn't handled directly by the main CPU, it's offloaded to
the ME (which we all know google loves because of its tight security
boundary). It is entirely possible to imagine a software interposer
running in the ME snooping the CRB buffer. A very different type of
attack from the LPB interposer, but plausible non the less.
James
Powered by blists - more mailing lists