linux-kernel - Re: [PATCH] tpm: Disable TPM2_TCG

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: <aMxZlHn9bfa5LGEU@kernel.org>
Date: Thu, 18 Sep 2025 22:12:20 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Jonathan McDowell <noodles@...th.li>
Cc: linux-integrity@...r.kernel.org, stable@...r.kernel.or,
	Chris Fenner <cfenn@...gle.com>, Peter Huewe <peterhuewe@....de>,
	Jason Gunthorpe <jgg@...pe.ca>, David Howells <dhowells@...hat.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:KEYS/KEYRINGS" <keyrings@...r.kernel.org>,
	"open list:SECURITY SUBSYSTEM" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] tpm: Disable TPM2_TCG_HMAC by default

On Thu, Sep 18, 2025 at 07:56:53PM +0100, Jonathan McDowell wrote:
> On Mon, Aug 25, 2025 at 11:32:23PM +0300, Jarkko Sakkinen wrote:
> > After reading all the feedback, right now disabling the TPM2_TCG_HMAC
> > is the right call.
> > 
> > Other views discussed:
> > 
> > A. Having a kernel command-line parameter or refining the feature
> >   otherwise. This goes to the area of improvements.  E.g., one
> >   example is my own idea where the null key specific code would be
> >   replaced with a persistent handle parameter (which can be
> >   *unambigously* defined as part of attestation process when
> >   done correctly).
> > 
> > B. Removing the code. I don't buy this because that is same as saying
> >   that HMAC encryption cannot work at all (if really nitpicking) in
> >   any form. Also I disagree on the view that the feature could not
> >   be refined to something more reasoable.
> > 
> > Also, both A and B are worst options in terms of backporting.
> > 
> > Thus, this is the best possible choice.
> 
> I think this is reasonable; it's adding runtime overhead and not adding
> enough benefit to be the default upstream.

Yes, I think this is a balanced change. I agree what you say and at the
same time this gives more space to refine it something usable. Right now
it is much harder to tackle those issue, as it is part of the default
config. By looking at things from this angle, the change is also
benefical for the feature itself (in the long run).

> Reviewed-By: Jonathan McDowell <noodles@...th.li>

Thank you! I appreciate this and will append this to the commit.

BR, Jarkko