linux-kernel - Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18

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: <aOP04Yy3m23E4kjf@kernel.org>
Date: Mon, 6 Oct 2025 19:57:05 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
	David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org,
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18

On Mon, Oct 06, 2025 at 07:51:51PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 06, 2025 at 10:33:40AM -0400, James Bottomley wrote:
> > On Mon, 2025-10-06 at 17:12 +0300, Jarkko Sakkinen wrote:
> > > 2. Null seed was extremely bad idea. The way I'm planning to actually
> > >    fix this is to parametrize the primary key to a persistent key
> > > handle
> > >    stored into nvram of the chip instead of genration. This will
> > > address
> > >    also ambiguity and can be linked directly to vendor ceritifcate
> > >    for e.g. to perfom remote attesttion.
> > 
> > Just a minute, there's been no discussion or debate about this on the
> > list.  The rationale for using the NULL seed is clearly laid out here:
> > 
> > https://docs.kernel.org/security/tpm/tpm-security.html
> > 
> > But in brief it is the only way to detect reset attacks against the TPM
> > and a reset attack is the single simplest attack an interposer can do.
> > 
> > If you think there's a problem with the approach, by all means let's
> > have a debate, since TPM security is always a trade off, but you can't
> > simply come to your own opinion and try to impose it by fiat without at
> > least raising whatever issue you think you've found with the parties
> > who contributed the code in the first place.
> 
> Ok fair enough, it's quite context dependent what is not secure and
> what is secure.
> 
> What I've thought, or have planned to implement, is not to discard null
> seed but instead parmetrize the primary key as a kernel command-line
> parameter.
> 
> E.g. "tpm.integrity_key={off,null,handle}" and
> "tpm.integrity_key_handle" to specify an NV index. The default value is
> off and I think also that with this change and possibly with some
> additional polishing it can reappear in default config,
> 
> This out of context for the PR but I will take your comment into account
> in the pull request.
> 
> My main issue preventing sending a new pull request is that weird list
> of core TPM2 features that is claimed "not to be required" with zero
> references. Especially it is contraditory claim that TPM2_CreatePrimary
> would be optional feature as the whole chip standard is based on three
> random seeds from which primary keys are templated and used as root
> keys for other keys.
> 
> So I guess I cherry-pick the claims from Chris' patch that I can cope
> with, look what I wrote to my commit and adjust that accordingly and
> finally write a tag message with summarization of all this. I exactly
> drop the arguments with no quantitative evidence, which is probably
> a sane way to move forward.

Personally I think that once there's correctly implemented command-line
option, the feature flag is somewhat redundant (and we've never had one
for /dev/tpmrm0). And it will help a lot with kernel QA as you can run
tests with same kernel image without recompilation.

BR, Jarkko