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

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] [day] [month] [year] [list]

Message-ID: <CAMigqh3yx7S2T=b-gTfdTG5BRs_JbHkXar4DT32AB3v_beNveA@mail.gmail.com>
Date: Fri, 15 Aug 2025 11:09:07 -0700
From: Chris Fenner <cfenn@...gle.com>
To: Jarkko Sakkinen <jarkko.sakkinen@....fi>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>, 
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tpm: Disable TCG_TPM2_HMAC by default

On Fri, Aug 15, 2025 at 10:45 AM Jarkko Sakkinen <jarkko@...nel.org> wrote:

> Primary key persistent handle.

I see, thanks. I think this might make it easier to ensure the driver
fails-open in the "relaxed" case, but I don't think it would resolve
much of the performance drawbacks (really we'd just cut out the
ContextLoads, which in my testing constitute around 30ms of the total
135ms of overhead). I still don't think it really solves the threat
model since the adversary can just make sure to interpose all the
requests instead of just some of them.

That said, it really seems prudent to disable the (seems to be?
broken) feature by default for now, then re-enable it once this is
confirmed working.

On Fri, Aug 15, 2025 at 10:52 AM Jarkko Sakkinen <jarkko@...nel.org> wrote:

> This is not to admit that right now the feature is no good to anyone
> but in a selected set of use cases with this modification it would
> make e.g., IMA's security *worse* than it would be with the feature
> enabled.

Under what specific threat model would IMA's security be worse in this
case? Either there is an interposer, or there isn't, right? If there
is an interposer, then they can interpose all the commands including
the CreatePrimary and session establishment(s) and defeat the current
and proposed version of TCG_TPM2_HMAC. If there is not an interposer,
then this is moot (I think).

Philosophically, I think there is no such thing as "more secure";
there is only "solves a stronger threat model." For example, you could
construct something called "AES-129" that you could argue is "more
secure" than AES-128, but since nobody's threat model has attackers
that can break 128-bit keys but not 129-bit keys, we don't use it. I
try to apply this reasoning to everything I build: all security
features trade-off against performance, usability, and compatibility,
and I strive to justify these trade-offs with whatever specific
threats that they resolve.

On Fri, Aug 15, 2025 at 11:04 AM Jarkko Sakkinen <jarkko.sakkinen@....fi> wrote:

> I'm happy to make patch next week for this change too. So probably this
> where I align myself to. It's just the best average IMHO. Everyone gets
> exactly what they want, right?

To be clear: I already have what I want (the ability to disable this
feature because it seems broken to me), I'm just making
recommendations as a TPM abyssal domain expert. I hope my feedback is
of some use on this -- the work of dealing with interposer attackers
is quite important and I appreciate the effort already put in by the
team.

Thanks
Chris