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
