From: Jarkko Sakkinen <jarkko@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
David Howells <dhowells@redhat.com>,
keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18
Date: Tue, 7 Oct 2025 17:38:50 +0300 [thread overview]
Message-ID: <aOUl-mZkRwJJwtJ7@kernel.org> (raw)
In-Reply-To: <aOUkcytS21zQs71I@kernel.org>
On Tue, Oct 07, 2025 at 05:32:24PM +0300, Jarkko Sakkinen wrote:
> On Mon, Oct 06, 2025 at 07:57:10PM +0300, Jarkko Sakkinen wrote:
> > 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.
>
> I don't really see any possible security issues either with null seed.
>
> It's no different as per remote attestation when compared storage keys.
> In a power cycle it's like same as per TPM2_Certify is considered. It's
> pretty much exactly performance issues but depending on deployment.
> Sometimes storage key root would be probably a better choice.
>
> I really tried to dig something else than exactly perf stuff but was
> unsuccessful to find anything, and I've actually done a lot of work
> at work on remote attestation so everything is also somewhat fresh
> on my mind.
>
> Still rooting to perf, immediate action being default option disable,
> and long term action being replacing the compilation option with
> kernel command-line options. I.e., I'll stay on track what I'e
> been already doing for some time :-)
>
> That said, my PR cover letter (or the tag message) did suck and
> I'll just address next during exactly why something is or isn't
> an issue. I think this is really good outcome for everyone in
> the long run (because everyone will get the outcome they were
> looking for).
And in the business I'm ATM i.e., covering like with 20-30% market share
Finnish high school IT deplyoment going extremes is feasible, as some
kids are smart and capable of hacking the systems so to speak ;-) I'd
likely enable this feature e.g., in that type of deployment together
with remote attesation just to max out defence in depth.
BR, Jarkko
next prev parent reply other threads:[~2025-10-07 14:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-05 15:47 [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18 Jarkko Sakkinen
2025-10-05 18:09 ` Linus Torvalds
2025-10-06 11:58 ` Jarkko Sakkinen
2025-10-06 14:12 ` Jarkko Sakkinen
2025-10-06 14:18 ` Jarkko Sakkinen
2025-10-06 14:30 ` Jarkko Sakkinen
2025-10-06 14:33 ` James Bottomley
2025-10-06 16:51 ` Jarkko Sakkinen
2025-10-06 16:57 ` Jarkko Sakkinen
2025-10-07 14:32 ` Jarkko Sakkinen
2025-10-07 14:38 ` Jarkko Sakkinen [this message]
2025-10-06 17:02 ` Jonathan McDowell
2025-10-06 18:50 ` Jarkko Sakkinen
2025-10-05 18:24 ` Linus Torvalds
2025-10-06 12:33 ` Jarkko Sakkinen
2025-10-06 21:40 ` Jonathan McDowell
2025-10-06 22:09 ` Linus Torvalds
2025-10-06 23:11 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOUl-mZkRwJJwtJ7@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dhowells@redhat.com \
--cc=jgg@ziepe.ca \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).