Re: [PATCH 01/17] tpm: Define a kernel-owned TPM NV index that can't be modified by userland

[Jarkko Sakkinen <jarkko@kernel.org>]

On Fri, Nov 13, 2026 at 02:40:39AM +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 08, 2026 at 06:20:17AM -0700, Matthew Garrett wrote:
> > +#ifdef CONFIG_TCG_TPM_KERNEL_NVINDEX
> > +/*
> > + * Commands that undefine or modify an NV index, and the position of the
> > + * NV index in the command's handle area.
> > + */
> > +static const struct {
> > +	u32 cc;
> > +	unsigned int handle;
> > +} tpm2_nv_modify_cmds[] = {
> > +	{ TPM2_CC_NV_UNDEFINE_SPACE_SPECIAL,	0 },
> > +	{ TPM2_CC_NV_UNDEFINE_SPACE,		1 },
> > +	{ TPM2_CC_NV_INCREMENT,			1 },
> > +	{ TPM2_CC_NV_SET_BITS,			1 },
> > +	{ TPM2_CC_NV_EXTEND,			1 },
> > +	{ TPM2_CC_NV_WRITE,			1 },
> > +	{ TPM2_CC_NV_WRITE_LOCK,		1 },
> > +	{ TPM2_CC_NV_CHANGE_AUTH,		0 },
> > +	{ TPM2_CC_NV_READ_LOCK,			1 },
> > +};
> 
> There's also tpm2_ordinal_duration_map:
> 
> 	static const struct {
> 		unsigned long ordinal;
> 		unsigned long duration;
> 	} tpm2_ordinal_duration_map[] = {
> 		{TPM2_CC_STARTUP, 750},
> 		{TPM2_CC_SELF_TEST, 3000},
> 		{TPM2_CC_GET_RANDOM, 2000},
> 		{TPM2_CC_SEQUENCE_UPDATE, 750},
> 		{TPM2_CC_SEQUENCE_COMPLETE, 750},
> 		{TPM2_CC_EVENT_SEQUENCE_COMPLETE, 750},
> 		{TPM2_CC_HASH_SEQUENCE_START, 750},
> 		{TPM2_CC_VERIFY_SIGNATURE, 30000},
> 		{TPM2_CC_PCR_EXTEND, 750},
> 		{TPM2_CC_HIERARCHY_CONTROL, 2000},
> 		{TPM2_CC_HIERARCHY_CHANGE_AUTH, 2000},
> 		{TPM2_CC_GET_CAPABILITY, 750},
> 		{TPM2_CC_NV_READ, 2000},
> 		{TPM2_CC_CREATE_PRIMARY, 300000},
> 		{TPM2_CC_CREATE, 300000},
> 		{TPM2_CC_CREATE_LOADED, 300000},
> 	};
> 
> I'd consider something along the lines of:
> 
> 	enum tpm2_cc_nv {
> 		TPM2_CC_NV_NA = -1,	/* not available */
> 		TPM2_CC_NV_H0 = 0,
> 		TPM2_CC_NV_H1 = 1,
> 	};
> 
> 	static const struct {
> 		u32 cc;
> 		u32 duration;
> 		enum tpm2_cc_nv nv;
> 	} tpm2_cc_map[] {
> 		/* ... */
> 	};
> 

And I'd do this as a separate patch without adding new command codes or
other NV specific shenanigans. I.e. all entries have just TPM2_CC_NV_NA
set.

Further I'd sequence this like:

1. A patch that does above refactor.
2. A patch that adds the mechanics. This is a point that can be already
   tested separately, thus it is important.
3. A patch that adds the new CC's and populates the entries to
   tpm2_cc_map.


Br, Jarkko