* Re: [PATCH 4/4] tpm: Move TPM common base definitions to the command header
From: Jarkko Sakkinen @ 2026-03-23 5:42 UTC (permalink / raw)
To: Alec Brown
Cc: linux-kernel, linux-integrity, peterhuewe, jarkko.sakkinen, jgg,
ross.philipson, dpsmith, daniel.kiper, kanth.ghatraju,
trenchboot-devel, ardb
In-Reply-To: <20260317160613.2899129-5-alec.r.brown@oracle.com>
On Tue, Mar 17, 2026 at 04:03:35PM +0000, Alec Brown wrote:
> From: Ross Philipson <ross.philipson@oracle.com>
>
> From: Ross Philipson <ross.philipson@oracle.com>
>
> These are top level definitions shared by both TPM 1 and 2
> family chips. This includes core definitions like TPM localities,
> common crypto algorithm IDs, and the base TPM command header.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> ---
> include/linux/tpm.h | 50 +--------------------
> include/linux/tpm_command.h | 89 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 90 insertions(+), 49 deletions(-)
>
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 92957452f7a7..a282b7045a24 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -27,49 +27,12 @@
>
> #include "tpm_command.h"
>
> -#define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> -
> -#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> -#define TPM2_MAX_PCR_BANKS 8
> -
> struct tpm_chip;
> struct trusted_key_payload;
> struct trusted_key_options;
> /* opaque structure, holds auth session parameters like the session key */
> struct tpm2_auth;
>
> -/* if you add a new hash to this, increment TPM_MAX_HASHES below */
> -enum tpm_algorithms {
> - TPM_ALG_ERROR = 0x0000,
> - TPM_ALG_SHA1 = 0x0004,
> - TPM_ALG_AES = 0x0006,
> - TPM_ALG_KEYEDHASH = 0x0008,
> - TPM_ALG_SHA256 = 0x000B,
> - TPM_ALG_SHA384 = 0x000C,
> - TPM_ALG_SHA512 = 0x000D,
> - TPM_ALG_NULL = 0x0010,
> - TPM_ALG_SM3_256 = 0x0012,
> - TPM_ALG_ECC = 0x0023,
> - TPM_ALG_CFB = 0x0043,
> -};
> -
> -/*
> - * maximum number of hashing algorithms a TPM can have. This is
> - * basically a count of every hash in tpm_algorithms above
> - */
> -#define TPM_MAX_HASHES 5
> -
> -struct tpm_digest {
> - u16 alg_id;
> - u8 digest[TPM2_MAX_DIGEST_SIZE];
> -} __packed;
> -
> -struct tpm_bank_info {
> - u16 alg_id;
> - u16 digest_size;
> - u16 crypto_id;
> -};
> -
> enum TPM_OPS_FLAGS {
> TPM_OPS_AUTO_STARTUP = BIT(0),
> };
> @@ -127,7 +90,7 @@ struct tpm_chip_seqops {
> const struct seq_operations *seqops;
> };
>
> -/* fixed define for the curve we use which is NIST_P256 */
> +/* Fixed define for the curve we use which is NIST_P256 */
> #define EC_PT_SZ 32
>
> /*
> @@ -209,8 +172,6 @@ struct tpm_chip {
> #endif
> };
>
> -#define TPM_HEADER_SIZE 10
> -
> static inline enum tpm2_mso_type tpm2_handle_mso(u32 handle)
> {
> return handle >> 24;
> @@ -239,15 +200,6 @@ enum tpm_chip_flags {
>
> #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
>
> -struct tpm_header {
> - __be16 tag;
> - __be32 length;
> - union {
> - __be32 ordinal;
> - __be32 return_code;
> - };
> -} __packed;
> -
> enum tpm_buf_flags {
> /* the capacity exceeded: */
> TPM_BUF_OVERFLOW = BIT(0),
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index ee76fcd5ecef..25a247254140 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -431,4 +431,93 @@ struct tpm2_context {
> __be16 blob_size;
> } __packed;
>
> +/************************************************/
> +/* TPM Common Defs */
> +/************************************************/
> +
> +#define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
> +#define TPM_BUFSIZE 4096
> +
> +/*
> + * SHA-512 is, as of today, the largest digest in the TCG algorithm repository.
> + */
> +#define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> +
> +/*
> + * A TPM name digest i.e., TPMT_HA, is a concatenation of TPM_ALG_ID of the
> + * name algorithm and hash of TPMT_PUBLIC.
> + */
> +#define TPM2_MAX_NAME_SIZE (TPM2_MAX_DIGEST_SIZE + 2)
> +
> +/*
> + * Fixed define for the size of a name. This is actually HASHALG size
> + * plus 2, so 32 for SHA256
> + */
> +#define TPM2_NULL_NAME_SIZE 34
> +
> +/*
> + * The maximum number of PCR banks.
> + */
> +#define TPM2_MAX_PCR_BANKS 8
> +
> +/* If you add a new hash to this, increment TPM_MAX_HASHES below */
> +enum tpm_algorithms {
> + TPM_ALG_ERROR = 0x0000,
> + TPM_ALG_SHA1 = 0x0004,
> + TPM_ALG_AES = 0x0006,
> + TPM_ALG_KEYEDHASH = 0x0008,
> + TPM_ALG_SHA256 = 0x000B,
> + TPM_ALG_SHA384 = 0x000C,
> + TPM_ALG_SHA512 = 0x000D,
> + TPM_ALG_NULL = 0x0010,
> + TPM_ALG_SM3_256 = 0x0012,
> + TPM_ALG_ECC = 0x0023,
> + TPM_ALG_CFB = 0x0043,
> +};
> +
> +/*
> + * The locality (0 - 4) for a TPM, as defined in section 3.2 of the
> + * Client Platform Profile Specification.
> + */
> +enum tpm_localities {
> + TPM_LOCALITY_0 = 0, /* Static RTM */
> + TPM_LOCALITY_1 = 1, /* Dynamic OS */
> + TPM_LOCALITY_2 = 2, /* DRTM Environment */
> + TPM_LOCALITY_3 = 3, /* Aux Components */
> + TPM_LOCALITY_4 = 4, /* CPU DRTM Establishment */
> + TPM_MAX_LOCALITY = TPM_LOCALITY_4
> +};
> +
> +/*
> + * Structure to represent active PCR algorithm banks usable by the
> + * TPM chip.
> + */
> +struct tpm_bank_info {
> + u16 alg_id;
> + u16 digest_size;
> + u16 crypto_id;
> +};
> +
> +/*
> + * Maximum number of hashing algorithms a TPM can have. This is
> + * basically a count of every hash in tpm_algorithms above
> + */
> +#define TPM_MAX_HASHES 5
> +
> +struct tpm_digest {
> + u16 alg_id;
> + u8 digest[TPM2_MAX_DIGEST_SIZE];
> +} __packed;
> +
> +#define TPM_HEADER_SIZE 10
> +
> +struct tpm_header {
> + __be16 tag;
> + __be32 length;
> + union {
> + __be32 ordinal;
> + __be32 return_code;
> + };
> +} __packed;
> +
> #endif
> --
> 2.47.3
>
Yep, all looks great and clean to me but exactly for that reason
this needs to the truth serum :-)
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 3/4] tpm: Move TPM2 specific definitions to the command header
From: Jarkko Sakkinen @ 2026-03-23 5:41 UTC (permalink / raw)
To: Alec Brown
Cc: linux-kernel, linux-integrity, peterhuewe, jarkko.sakkinen, jgg,
ross.philipson, dpsmith, daniel.kiper, kanth.ghatraju,
trenchboot-devel, ardb
In-Reply-To: <20260317160613.2899129-4-alec.r.brown@oracle.com>
On Tue, Mar 17, 2026 at 04:03:34PM +0000, Alec Brown wrote:
> From: Ross Philipson <ross.philipson@oracle.com>
>
> From: Ross Philipson <ross.philipson@oracle.com>
Address this for +1 version but hold on until I have time to test
this (next week latest), as that might generate some additional
feedback.
>
> Gather all the TPM2 definitions and structures in the internal header
> file drivers/char/tpm/tpm.h into the command header, including:
> - Command codes, return codes and definitions from the public and
> internal tpm.h files.
> - Structures defined in numerous TPM driver C modules.
>
> The definitions moved to these files correspond to the TCG specification
> for TPM 2 family:
>
> TPM 2.0 Library
> - https://trustedcomputinggroup.org/resource/tpm-library-specification/
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> ---
> drivers/char/tpm/tpm.h | 77 ----------
> drivers/char/tpm/tpm2-cmd.c | 30 ----
> drivers/char/tpm/tpm2-space.c | 13 --
> include/linux/tpm.h | 145 ------------------
> include/linux/tpm_command.h | 273 ++++++++++++++++++++++++++++++++++
> 5 files changed, 273 insertions(+), 265 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 1a9a46a921fe..147e57c0e7bb 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -51,83 +51,6 @@ enum tpm_addr {
> TPM_ADDR = 0x4E,
> };
>
> -/* TPM2 specific constants. */
> -#define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
> -
> -enum tpm2_pt_props {
> - TPM2_PT_NONE = 0x00000000,
> - TPM2_PT_GROUP = 0x00000100,
> - TPM2_PT_FIXED = TPM2_PT_GROUP * 1,
> - TPM2_PT_FAMILY_INDICATOR = TPM2_PT_FIXED + 0,
> - TPM2_PT_LEVEL = TPM2_PT_FIXED + 1,
> - TPM2_PT_REVISION = TPM2_PT_FIXED + 2,
> - TPM2_PT_DAY_OF_YEAR = TPM2_PT_FIXED + 3,
> - TPM2_PT_YEAR = TPM2_PT_FIXED + 4,
> - TPM2_PT_MANUFACTURER = TPM2_PT_FIXED + 5,
> - TPM2_PT_VENDOR_STRING_1 = TPM2_PT_FIXED + 6,
> - TPM2_PT_VENDOR_STRING_2 = TPM2_PT_FIXED + 7,
> - TPM2_PT_VENDOR_STRING_3 = TPM2_PT_FIXED + 8,
> - TPM2_PT_VENDOR_STRING_4 = TPM2_PT_FIXED + 9,
> - TPM2_PT_VENDOR_TPM_TYPE = TPM2_PT_FIXED + 10,
> - TPM2_PT_FIRMWARE_VERSION_1 = TPM2_PT_FIXED + 11,
> - TPM2_PT_FIRMWARE_VERSION_2 = TPM2_PT_FIXED + 12,
> - TPM2_PT_INPUT_BUFFER = TPM2_PT_FIXED + 13,
> - TPM2_PT_HR_TRANSIENT_MIN = TPM2_PT_FIXED + 14,
> - TPM2_PT_HR_PERSISTENT_MIN = TPM2_PT_FIXED + 15,
> - TPM2_PT_HR_LOADED_MIN = TPM2_PT_FIXED + 16,
> - TPM2_PT_ACTIVE_SESSIONS_MAX = TPM2_PT_FIXED + 17,
> - TPM2_PT_PCR_COUNT = TPM2_PT_FIXED + 18,
> - TPM2_PT_PCR_SELECT_MIN = TPM2_PT_FIXED + 19,
> - TPM2_PT_CONTEXT_GAP_MAX = TPM2_PT_FIXED + 20,
> - TPM2_PT_NV_COUNTERS_MAX = TPM2_PT_FIXED + 22,
> - TPM2_PT_NV_INDEX_MAX = TPM2_PT_FIXED + 23,
> - TPM2_PT_MEMORY = TPM2_PT_FIXED + 24,
> - TPM2_PT_CLOCK_UPDATE = TPM2_PT_FIXED + 25,
> - TPM2_PT_CONTEXT_HASH = TPM2_PT_FIXED + 26,
> - TPM2_PT_CONTEXT_SYM = TPM2_PT_FIXED + 27,
> - TPM2_PT_CONTEXT_SYM_SIZE = TPM2_PT_FIXED + 28,
> - TPM2_PT_ORDERLY_COUNT = TPM2_PT_FIXED + 29,
> - TPM2_PT_MAX_COMMAND_SIZE = TPM2_PT_FIXED + 30,
> - TPM2_PT_MAX_RESPONSE_SIZE = TPM2_PT_FIXED + 31,
> - TPM2_PT_MAX_DIGEST = TPM2_PT_FIXED + 32,
> - TPM2_PT_MAX_OBJECT_CONTEXT = TPM2_PT_FIXED + 33,
> - TPM2_PT_MAX_SESSION_CONTEXT = TPM2_PT_FIXED + 34,
> - TPM2_PT_PS_FAMILY_INDICATOR = TPM2_PT_FIXED + 35,
> - TPM2_PT_PS_LEVEL = TPM2_PT_FIXED + 36,
> - TPM2_PT_PS_REVISION = TPM2_PT_FIXED + 37,
> - TPM2_PT_PS_DAY_OF_YEAR = TPM2_PT_FIXED + 38,
> - TPM2_PT_PS_YEAR = TPM2_PT_FIXED + 39,
> - TPM2_PT_SPLIT_MAX = TPM2_PT_FIXED + 40,
> - TPM2_PT_TOTAL_COMMANDS = TPM2_PT_FIXED + 41,
> - TPM2_PT_LIBRARY_COMMANDS = TPM2_PT_FIXED + 42,
> - TPM2_PT_VENDOR_COMMANDS = TPM2_PT_FIXED + 43,
> - TPM2_PT_NV_BUFFER_MAX = TPM2_PT_FIXED + 44,
> - TPM2_PT_MODES = TPM2_PT_FIXED + 45,
> - TPM2_PT_MAX_CAP_BUFFER = TPM2_PT_FIXED + 46,
> - TPM2_PT_VAR = TPM2_PT_GROUP * 2,
> - TPM2_PT_PERMANENT = TPM2_PT_VAR + 0,
> - TPM2_PT_STARTUP_CLEAR = TPM2_PT_VAR + 1,
> - TPM2_PT_HR_NV_INDEX = TPM2_PT_VAR + 2,
> - TPM2_PT_HR_LOADED = TPM2_PT_VAR + 3,
> - TPM2_PT_HR_LOADED_AVAIL = TPM2_PT_VAR + 4,
> - TPM2_PT_HR_ACTIVE = TPM2_PT_VAR + 5,
> - TPM2_PT_HR_ACTIVE_AVAIL = TPM2_PT_VAR + 6,
> - TPM2_PT_HR_TRANSIENT_AVAIL = TPM2_PT_VAR + 7,
> - TPM2_PT_HR_PERSISTENT = TPM2_PT_VAR + 8,
> - TPM2_PT_HR_PERSISTENT_AVAIL = TPM2_PT_VAR + 9,
> - TPM2_PT_NV_COUNTERS = TPM2_PT_VAR + 10,
> - TPM2_PT_NV_COUNTERS_AVAIL = TPM2_PT_VAR + 11,
> - TPM2_PT_ALGORITHM_SET = TPM2_PT_VAR + 12,
> - TPM2_PT_LOADED_CURVES = TPM2_PT_VAR + 13,
> - TPM2_PT_LOCKOUT_COUNTER = TPM2_PT_VAR + 14,
> - TPM2_PT_MAX_AUTH_FAIL = TPM2_PT_VAR + 15,
> - TPM2_PT_LOCKOUT_INTERVAL = TPM2_PT_VAR + 16,
> - TPM2_PT_LOCKOUT_RECOVERY = TPM2_PT_VAR + 17,
> - TPM2_PT_NV_WRITE_RECOVERY = TPM2_PT_VAR + 18,
> - TPM2_PT_AUDIT_COUNTER_0 = TPM2_PT_VAR + 19,
> - TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
> -};
> -
> extern const struct class tpm_class;
> extern const struct class tpmrm_class;
> extern dev_t tpm_devt;
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index 3a77be7ebf4a..1fa3e8a43c79 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -94,17 +94,6 @@ unsigned long tpm2_calc_ordinal_duration(u32 ordinal)
> return msecs_to_jiffies(TPM2_DURATION_DEFAULT);
> }
>
> -struct tpm2_pcr_read_out {
> - __be32 update_cnt;
> - __be32 pcr_selects_cnt;
> - __be16 hash_alg;
> - u8 pcr_select_size;
> - u8 pcr_select[TPM2_PCR_SELECT_MIN];
> - __be32 digests_cnt;
> - __be16 digest_size;
> - u8 digest[];
> -} __packed;
> -
> /**
> * tpm2_pcr_read() - read a PCR value
> * @chip: TPM chip to use.
> @@ -238,11 +227,6 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> return rc;
> }
>
> -struct tpm2_get_random_out {
> - __be16 size;
> - u8 buffer[TPM_MAX_RNG_DATA];
> -} __packed;
> -
> /**
> * tpm2_get_random() - get random bytes from the TPM RNG
> *
> @@ -366,14 +350,6 @@ void tpm2_flush_context(struct tpm_chip *chip, u32 handle)
> }
> EXPORT_SYMBOL_GPL(tpm2_flush_context);
>
> -struct tpm2_get_cap_out {
> - u8 more_data;
> - __be32 subcap_id;
> - __be32 property_cnt;
> - __be32 property_id;
> - __be32 value;
> -} __packed;
> -
> /**
> * tpm2_get_tpm_pt() - get value of a TPM_CAP_TPM_PROPERTIES type property
> * @chip: a &tpm_chip instance
> @@ -541,12 +517,6 @@ static int tpm2_init_bank_info(struct tpm_chip *chip, u32 bank_index)
> return tpm2_pcr_read(chip, 0, &digest, &bank->digest_size);
> }
>
> -struct tpm2_pcr_selection {
> - __be16 hash_alg;
> - u8 size_of_select;
> - u8 pcr_select[3];
> -} __packed;
> -
> ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
> {
> struct tpm2_pcr_selection pcr_selection;
> diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index 60354cd53b5c..7c1c0a174a2b 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -15,19 +15,6 @@
> #include <linux/unaligned.h>
> #include "tpm.h"
>
> -enum tpm2_handle_types {
> - TPM2_HT_HMAC_SESSION = 0x02000000,
> - TPM2_HT_POLICY_SESSION = 0x03000000,
> - TPM2_HT_TRANSIENT = 0x80000000,
> -};
> -
> -struct tpm2_context {
> - __be64 sequence;
> - __be32 saved_handle;
> - __be32 hierarchy;
> - __be16 blob_size;
> -} __packed;
> -
> static void tpm2_flush_sessions(struct tpm_chip *chip, struct tpm_space *space)
> {
> int i;
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 18dcf0ef46f6..92957452f7a7 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -38,12 +38,6 @@ struct trusted_key_options;
> /* opaque structure, holds auth session parameters like the session key */
> struct tpm2_auth;
>
> -enum tpm2_session_types {
> - TPM2_SE_HMAC = 0x00,
> - TPM2_SE_POLICY = 0x01,
> - TPM2_SE_TRIAL = 0x02,
> -};
> -
> /* if you add a new hash to this, increment TPM_MAX_HASHES below */
> enum tpm_algorithms {
> TPM_ALG_ERROR = 0x0000,
> @@ -65,11 +59,6 @@ enum tpm_algorithms {
> */
> #define TPM_MAX_HASHES 5
>
> -enum tpm2_curves {
> - TPM2_ECC_NONE = 0x0000,
> - TPM2_ECC_NIST_P256 = 0x0003,
> -};
> -
> struct tpm_digest {
> u16 alg_id;
> u8 digest[TPM2_MAX_DIGEST_SIZE];
> @@ -222,122 +211,11 @@ struct tpm_chip {
>
> #define TPM_HEADER_SIZE 10
>
> -enum tpm2_const {
> - TPM2_PLATFORM_PCR = 24,
> - TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
> -};
> -
> -enum tpm2_timeouts {
> - TPM2_TIMEOUT_A = 750,
> - TPM2_TIMEOUT_B = 4000,
> - TPM2_TIMEOUT_C = 200,
> - TPM2_TIMEOUT_D = 30,
> -};
> -
> -enum tpm2_durations {
> - TPM2_DURATION_SHORT = 20,
> - TPM2_DURATION_LONG = 2000,
> - TPM2_DURATION_DEFAULT = 120000,
> -};
> -
> -enum tpm2_structures {
> - TPM2_ST_NO_SESSIONS = 0x8001,
> - TPM2_ST_SESSIONS = 0x8002,
> - TPM2_ST_CREATION = 0x8021,
> -};
> -
> -/* Indicates from what layer of the software stack the error comes from */
> -#define TSS2_RC_LAYER_SHIFT 16
> -#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT)
> -
> -enum tpm2_return_codes {
> - TPM2_RC_SUCCESS = 0x0000,
> - TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
> - TPM2_RC_HANDLE = 0x008B,
> - TPM2_RC_INTEGRITY = 0x009F,
> - TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
> - TPM2_RC_FAILURE = 0x0101,
> - TPM2_RC_DISABLED = 0x0120,
> - TPM2_RC_UPGRADE = 0x012D,
> - TPM2_RC_COMMAND_CODE = 0x0143,
> - TPM2_RC_TESTING = 0x090A, /* RC_WARN */
> - TPM2_RC_REFERENCE_H0 = 0x0910,
> - TPM2_RC_RETRY = 0x0922,
> - TPM2_RC_SESSION_MEMORY = 0x0903,
> -};
> -
> -enum tpm2_command_codes {
> - TPM2_CC_FIRST = 0x011F,
> - TPM2_CC_HIERARCHY_CONTROL = 0x0121,
> - TPM2_CC_HIERARCHY_CHANGE_AUTH = 0x0129,
> - TPM2_CC_CREATE_PRIMARY = 0x0131,
> - TPM2_CC_SEQUENCE_COMPLETE = 0x013E,
> - TPM2_CC_SELF_TEST = 0x0143,
> - TPM2_CC_STARTUP = 0x0144,
> - TPM2_CC_SHUTDOWN = 0x0145,
> - TPM2_CC_NV_READ = 0x014E,
> - TPM2_CC_CREATE = 0x0153,
> - TPM2_CC_LOAD = 0x0157,
> - TPM2_CC_SEQUENCE_UPDATE = 0x015C,
> - TPM2_CC_UNSEAL = 0x015E,
> - TPM2_CC_CONTEXT_LOAD = 0x0161,
> - TPM2_CC_CONTEXT_SAVE = 0x0162,
> - TPM2_CC_FLUSH_CONTEXT = 0x0165,
> - TPM2_CC_READ_PUBLIC = 0x0173,
> - TPM2_CC_START_AUTH_SESS = 0x0176,
> - TPM2_CC_VERIFY_SIGNATURE = 0x0177,
> - TPM2_CC_GET_CAPABILITY = 0x017A,
> - TPM2_CC_GET_RANDOM = 0x017B,
> - TPM2_CC_PCR_READ = 0x017E,
> - TPM2_CC_PCR_EXTEND = 0x0182,
> - TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
> - TPM2_CC_HASH_SEQUENCE_START = 0x0186,
> - TPM2_CC_CREATE_LOADED = 0x0191,
> - TPM2_CC_LAST = 0x0193, /* Spec 1.36 */
> -};
> -
> -enum tpm2_permanent_handles {
> - TPM2_RH_NULL = 0x40000007,
> - TPM2_RS_PW = 0x40000009,
> -};
> -
> -/* Most Significant Octet for key types */
> -enum tpm2_mso_type {
> - TPM2_MSO_NVRAM = 0x01,
> - TPM2_MSO_SESSION = 0x02,
> - TPM2_MSO_POLICY = 0x03,
> - TPM2_MSO_PERMANENT = 0x40,
> - TPM2_MSO_VOLATILE = 0x80,
> - TPM2_MSO_PERSISTENT = 0x81,
> -};
> -
> static inline enum tpm2_mso_type tpm2_handle_mso(u32 handle)
> {
> return handle >> 24;
> }
>
> -enum tpm2_capabilities {
> - TPM2_CAP_HANDLES = 1,
> - TPM2_CAP_COMMANDS = 2,
> - TPM2_CAP_PCRS = 5,
> - TPM2_CAP_TPM_PROPERTIES = 6,
> -};
> -
> -enum tpm2_properties {
> - TPM_PT_TOTAL_COMMANDS = 0x0129,
> -};
> -
> -enum tpm2_startup_types {
> - TPM2_SU_CLEAR = 0x0000,
> - TPM2_SU_STATE = 0x0001,
> -};
> -
> -enum tpm2_cc_attrs {
> - TPM2_CC_ATTR_CHANDLES = 25,
> - TPM2_CC_ATTR_RHANDLE = 28,
> - TPM2_CC_ATTR_VENDOR = 29,
> -};
> -
> #define TPM_VID_INTEL 0x8086
> #define TPM_VID_WINBOND 0x1050
> #define TPM_VID_STM 0x104A
> @@ -389,29 +267,6 @@ struct tpm_buf {
> u8 handles;
> };
>
> -enum tpm2_object_attributes {
> - TPM2_OA_FIXED_TPM = BIT(1),
> - TPM2_OA_ST_CLEAR = BIT(2),
> - TPM2_OA_FIXED_PARENT = BIT(4),
> - TPM2_OA_SENSITIVE_DATA_ORIGIN = BIT(5),
> - TPM2_OA_USER_WITH_AUTH = BIT(6),
> - TPM2_OA_ADMIN_WITH_POLICY = BIT(7),
> - TPM2_OA_NO_DA = BIT(10),
> - TPM2_OA_ENCRYPTED_DUPLICATION = BIT(11),
> - TPM2_OA_RESTRICTED = BIT(16),
> - TPM2_OA_DECRYPT = BIT(17),
> - TPM2_OA_SIGN = BIT(18),
> -};
> -
> -enum tpm2_session_attributes {
> - TPM2_SA_CONTINUE_SESSION = BIT(0),
> - TPM2_SA_AUDIT_EXCLUSIVE = BIT(1),
> - TPM2_SA_AUDIT_RESET = BIT(3),
> - TPM2_SA_DECRYPT = BIT(5),
> - TPM2_SA_ENCRYPT = BIT(6),
> - TPM2_SA_AUDIT = BIT(7),
> -};
> -
> struct tpm2_hash {
> unsigned int crypto_id;
> unsigned int tpm_id;
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index 20b634591fb1..ee76fcd5ecef 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -158,4 +158,277 @@ struct tpm1_get_random_out {
> #define TPM_NONCE_SIZE 20
> #define TPM_ST_CLEAR 1
>
> +/************************************************/
> +/* TPM 2 Family Chips */
> +/************************************************/
> +
> +/*
> + * TPM 2.0 Library
> + * https://trustedcomputinggroup.org/resource/tpm-library-specification/
> + */
> +
> +/* TPM2 specific constants. */
> +#define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
> +
> +enum tpm2_session_types {
> + TPM2_SE_HMAC = 0x00,
> + TPM2_SE_POLICY = 0x01,
> + TPM2_SE_TRIAL = 0x02,
> +};
> +
> +enum tpm2_timeouts {
> + TPM2_TIMEOUT_A = 750,
> + TPM2_TIMEOUT_B = 4000,
> + TPM2_TIMEOUT_C = 200,
> + TPM2_TIMEOUT_D = 30,
> + TPM2_DURATION_SHORT = 20,
> + TPM2_DURATION_MEDIUM = 750,
> + TPM2_DURATION_LONG = 2000,
> + TPM2_DURATION_LONG_LONG = 300000,
> + TPM2_DURATION_DEFAULT = 120000,
> +};
> +
> +enum tpm2_structures {
> + TPM2_ST_NO_SESSIONS = 0x8001,
> + TPM2_ST_SESSIONS = 0x8002,
> + TPM2_ST_CREATION = 0x8021,
> +};
> +
> +/* Indicates from what layer of the software stack the error comes from */
> +#define TSS2_RC_LAYER_SHIFT 16
> +#define TSS2_RESMGR_TPM_RC_LAYER (11 << TSS2_RC_LAYER_SHIFT)
> +
> +enum tpm2_return_codes {
> + TPM2_RC_SUCCESS = 0x0000,
> + TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
> + TPM2_RC_HANDLE = 0x008B,
> + TPM2_RC_INTEGRITY = 0x009F,
> + TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
> + TPM2_RC_FAILURE = 0x0101,
> + TPM2_RC_DISABLED = 0x0120,
> + TPM2_RC_UPGRADE = 0x012D,
> + TPM2_RC_COMMAND_CODE = 0x0143,
> + TPM2_RC_TESTING = 0x090A, /* RC_WARN */
> + TPM2_RC_REFERENCE_H0 = 0x0910,
> + TPM2_RC_RETRY = 0x0922,
> + TPM2_RC_SESSION_MEMORY = 0x0903,
> +};
> +
> +enum tpm2_command_codes {
> + TPM2_CC_FIRST = 0x011F,
> + TPM2_CC_HIERARCHY_CONTROL = 0x0121,
> + TPM2_CC_HIERARCHY_CHANGE_AUTH = 0x0129,
> + TPM2_CC_CREATE_PRIMARY = 0x0131,
> + TPM2_CC_SEQUENCE_COMPLETE = 0x013E,
> + TPM2_CC_SELF_TEST = 0x0143,
> + TPM2_CC_STARTUP = 0x0144,
> + TPM2_CC_SHUTDOWN = 0x0145,
> + TPM2_CC_NV_READ = 0x014E,
> + TPM2_CC_CREATE = 0x0153,
> + TPM2_CC_LOAD = 0x0157,
> + TPM2_CC_SEQUENCE_UPDATE = 0x015C,
> + TPM2_CC_UNSEAL = 0x015E,
> + TPM2_CC_CONTEXT_LOAD = 0x0161,
> + TPM2_CC_CONTEXT_SAVE = 0x0162,
> + TPM2_CC_FLUSH_CONTEXT = 0x0165,
> + TPM2_CC_READ_PUBLIC = 0x0173,
> + TPM2_CC_START_AUTH_SESS = 0x0176,
> + TPM2_CC_VERIFY_SIGNATURE = 0x0177,
> + TPM2_CC_GET_CAPABILITY = 0x017A,
> + TPM2_CC_GET_RANDOM = 0x017B,
> + TPM2_CC_PCR_READ = 0x017E,
> + TPM2_CC_PCR_EXTEND = 0x0182,
> + TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
> + TPM2_CC_HASH_SEQUENCE_START = 0x0186,
> + TPM2_CC_CREATE_LOADED = 0x0191,
> + TPM2_CC_LAST = 0x0193, /* Spec 1.36 */
> +};
> +
> +enum tpm2_capabilities {
> + TPM2_CAP_HANDLES = 1,
> + TPM2_CAP_COMMANDS = 2,
> + TPM2_CAP_PCRS = 5,
> + TPM2_CAP_TPM_PROPERTIES = 6,
> +};
> +
> +enum tpm2_properties {
> + TPM_PT_TOTAL_COMMANDS = 0x0129,
> +};
> +
> +enum tpm2_startup_types {
> + TPM2_SU_CLEAR = 0x0000,
> + TPM2_SU_STATE = 0x0001,
> +};
> +
> +enum tpm2_cc_attrs {
> + TPM2_CC_ATTR_CHANDLES = 25,
> + TPM2_CC_ATTR_RHANDLE = 28,
> + TPM2_CC_ATTR_VENDOR = 29,
> +};
> +
> +enum tpm2_permanent_handles {
> + TPM2_RH_NULL = 0x40000007,
> + TPM2_RS_PW = 0x40000009,
> +};
> +
> +/* Most Significant Octet for key types */
> +enum tpm2_mso_type {
> + TPM2_MSO_NVRAM = 0x01,
> + TPM2_MSO_SESSION = 0x02,
> + TPM2_MSO_POLICY = 0x03,
> + TPM2_MSO_PERMANENT = 0x40,
> + TPM2_MSO_VOLATILE = 0x80,
> + TPM2_MSO_PERSISTENT = 0x81,
> +};
> +
> +enum tpm2_curves {
> + TPM2_ECC_NONE = 0x0000,
> + TPM2_ECC_NIST_P256 = 0x0003,
> +};
> +
> +enum tpm2_object_attributes {
> + TPM2_OA_FIXED_TPM = BIT(1),
> + TPM2_OA_ST_CLEAR = BIT(2),
> + TPM2_OA_FIXED_PARENT = BIT(4),
> + TPM2_OA_SENSITIVE_DATA_ORIGIN = BIT(5),
> + TPM2_OA_USER_WITH_AUTH = BIT(6),
> + TPM2_OA_ADMIN_WITH_POLICY = BIT(7),
> + TPM2_OA_NO_DA = BIT(10),
> + TPM2_OA_ENCRYPTED_DUPLICATION = BIT(11),
> + TPM2_OA_RESTRICTED = BIT(16),
> + TPM2_OA_DECRYPT = BIT(17),
> + TPM2_OA_SIGN = BIT(18),
> +};
> +
> +enum tpm2_session_attributes {
> + TPM2_SA_CONTINUE_SESSION = BIT(0),
> + TPM2_SA_AUDIT_EXCLUSIVE = BIT(1),
> + TPM2_SA_AUDIT_RESET = BIT(3),
> + TPM2_SA_DECRYPT = BIT(5),
> + TPM2_SA_ENCRYPT = BIT(6),
> + TPM2_SA_AUDIT = BIT(7),
> +};
> +
> +enum tpm2_pcr_select {
> + TPM2_PLATFORM_PCR = 24,
> + TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
> +};
> +
> +enum tpm2_handle_types {
> + TPM2_HT_HMAC_SESSION = 0x02000000,
> + TPM2_HT_POLICY_SESSION = 0x03000000,
> + TPM2_HT_TRANSIENT = 0x80000000,
> +};
> +
> +enum tpm2_pt_props {
> + TPM2_PT_NONE = 0x00000000,
> + TPM2_PT_GROUP = 0x00000100,
> + TPM2_PT_FIXED = TPM2_PT_GROUP * 1,
> + TPM2_PT_FAMILY_INDICATOR = TPM2_PT_FIXED + 0,
> + TPM2_PT_LEVEL = TPM2_PT_FIXED + 1,
> + TPM2_PT_REVISION = TPM2_PT_FIXED + 2,
> + TPM2_PT_DAY_OF_YEAR = TPM2_PT_FIXED + 3,
> + TPM2_PT_YEAR = TPM2_PT_FIXED + 4,
> + TPM2_PT_MANUFACTURER = TPM2_PT_FIXED + 5,
> + TPM2_PT_VENDOR_STRING_1 = TPM2_PT_FIXED + 6,
> + TPM2_PT_VENDOR_STRING_2 = TPM2_PT_FIXED + 7,
> + TPM2_PT_VENDOR_STRING_3 = TPM2_PT_FIXED + 8,
> + TPM2_PT_VENDOR_STRING_4 = TPM2_PT_FIXED + 9,
> + TPM2_PT_VENDOR_TPM_TYPE = TPM2_PT_FIXED + 10,
> + TPM2_PT_FIRMWARE_VERSION_1 = TPM2_PT_FIXED + 11,
> + TPM2_PT_FIRMWARE_VERSION_2 = TPM2_PT_FIXED + 12,
> + TPM2_PT_INPUT_BUFFER = TPM2_PT_FIXED + 13,
> + TPM2_PT_HR_TRANSIENT_MIN = TPM2_PT_FIXED + 14,
> + TPM2_PT_HR_PERSISTENT_MIN = TPM2_PT_FIXED + 15,
> + TPM2_PT_HR_LOADED_MIN = TPM2_PT_FIXED + 16,
> + TPM2_PT_ACTIVE_SESSIONS_MAX = TPM2_PT_FIXED + 17,
> + TPM2_PT_PCR_COUNT = TPM2_PT_FIXED + 18,
> + TPM2_PT_PCR_SELECT_MIN = TPM2_PT_FIXED + 19,
> + TPM2_PT_CONTEXT_GAP_MAX = TPM2_PT_FIXED + 20,
> + TPM2_PT_NV_COUNTERS_MAX = TPM2_PT_FIXED + 22,
> + TPM2_PT_NV_INDEX_MAX = TPM2_PT_FIXED + 23,
> + TPM2_PT_MEMORY = TPM2_PT_FIXED + 24,
> + TPM2_PT_CLOCK_UPDATE = TPM2_PT_FIXED + 25,
> + TPM2_PT_CONTEXT_HASH = TPM2_PT_FIXED + 26,
> + TPM2_PT_CONTEXT_SYM = TPM2_PT_FIXED + 27,
> + TPM2_PT_CONTEXT_SYM_SIZE = TPM2_PT_FIXED + 28,
> + TPM2_PT_ORDERLY_COUNT = TPM2_PT_FIXED + 29,
> + TPM2_PT_MAX_COMMAND_SIZE = TPM2_PT_FIXED + 30,
> + TPM2_PT_MAX_RESPONSE_SIZE = TPM2_PT_FIXED + 31,
> + TPM2_PT_MAX_DIGEST = TPM2_PT_FIXED + 32,
> + TPM2_PT_MAX_OBJECT_CONTEXT = TPM2_PT_FIXED + 33,
> + TPM2_PT_MAX_SESSION_CONTEXT = TPM2_PT_FIXED + 34,
> + TPM2_PT_PS_FAMILY_INDICATOR = TPM2_PT_FIXED + 35,
> + TPM2_PT_PS_LEVEL = TPM2_PT_FIXED + 36,
> + TPM2_PT_PS_REVISION = TPM2_PT_FIXED + 37,
> + TPM2_PT_PS_DAY_OF_YEAR = TPM2_PT_FIXED + 38,
> + TPM2_PT_PS_YEAR = TPM2_PT_FIXED + 39,
> + TPM2_PT_SPLIT_MAX = TPM2_PT_FIXED + 40,
> + TPM2_PT_TOTAL_COMMANDS = TPM2_PT_FIXED + 41,
> + TPM2_PT_LIBRARY_COMMANDS = TPM2_PT_FIXED + 42,
> + TPM2_PT_VENDOR_COMMANDS = TPM2_PT_FIXED + 43,
> + TPM2_PT_NV_BUFFER_MAX = TPM2_PT_FIXED + 44,
> + TPM2_PT_MODES = TPM2_PT_FIXED + 45,
> + TPM2_PT_MAX_CAP_BUFFER = TPM2_PT_FIXED + 46,
> + TPM2_PT_VAR = TPM2_PT_GROUP * 2,
> + TPM2_PT_PERMANENT = TPM2_PT_VAR + 0,
> + TPM2_PT_STARTUP_CLEAR = TPM2_PT_VAR + 1,
> + TPM2_PT_HR_NV_INDEX = TPM2_PT_VAR + 2,
> + TPM2_PT_HR_LOADED = TPM2_PT_VAR + 3,
> + TPM2_PT_HR_LOADED_AVAIL = TPM2_PT_VAR + 4,
> + TPM2_PT_HR_ACTIVE = TPM2_PT_VAR + 5,
> + TPM2_PT_HR_ACTIVE_AVAIL = TPM2_PT_VAR + 6,
> + TPM2_PT_HR_TRANSIENT_AVAIL = TPM2_PT_VAR + 7,
> + TPM2_PT_HR_PERSISTENT = TPM2_PT_VAR + 8,
> + TPM2_PT_HR_PERSISTENT_AVAIL = TPM2_PT_VAR + 9,
> + TPM2_PT_NV_COUNTERS = TPM2_PT_VAR + 10,
> + TPM2_PT_NV_COUNTERS_AVAIL = TPM2_PT_VAR + 11,
> + TPM2_PT_ALGORITHM_SET = TPM2_PT_VAR + 12,
> + TPM2_PT_LOADED_CURVES = TPM2_PT_VAR + 13,
> + TPM2_PT_LOCKOUT_COUNTER = TPM2_PT_VAR + 14,
> + TPM2_PT_MAX_AUTH_FAIL = TPM2_PT_VAR + 15,
> + TPM2_PT_LOCKOUT_INTERVAL = TPM2_PT_VAR + 16,
> + TPM2_PT_LOCKOUT_RECOVERY = TPM2_PT_VAR + 17,
> + TPM2_PT_NV_WRITE_RECOVERY = TPM2_PT_VAR + 18,
> + TPM2_PT_AUDIT_COUNTER_0 = TPM2_PT_VAR + 19,
> + TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
> +};
> +
> +struct tpm2_pcr_read_out {
> + __be32 update_cnt;
> + __be32 pcr_selects_cnt;
> + __be16 hash_alg;
> + u8 pcr_select_size;
> + u8 pcr_select[TPM2_PCR_SELECT_MIN];
> + __be32 digests_cnt;
> + __be16 digest_size;
> + u8 digest[];
> +} __packed;
> +
> +struct tpm2_get_random_out {
> + __be16 size;
> + u8 buffer[TPM_MAX_RNG_DATA];
> +} __packed;
> +
> +struct tpm2_get_cap_out {
> + u8 more_data;
> + __be32 subcap_id;
> + __be32 property_cnt;
> + __be32 property_id;
> + __be32 value;
> +} __packed;
> +
> +struct tpm2_pcr_selection {
> + __be16 hash_alg;
> + u8 size_of_select;
> + u8 pcr_select[3];
> +} __packed;
> +
> +struct tpm2_context {
> + __be64 sequence;
> + __be32 saved_handle;
> + __be32 hierarchy;
> + __be16 blob_size;
> +} __packed;
> +
> #endif
> --
> 2.47.3
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH 1/4] tpm: Initial step to reorganize TPM public headers
From: Jarkko Sakkinen @ 2026-03-23 5:39 UTC (permalink / raw)
To: Alec Brown
Cc: linux-kernel, linux-integrity, peterhuewe, jarkko.sakkinen, jgg,
ross.philipson, dpsmith, daniel.kiper, kanth.ghatraju,
trenchboot-devel, ardb
In-Reply-To: <20260317160613.2899129-2-alec.r.brown@oracle.com>
On Tue, Mar 17, 2026 at 04:03:32PM +0000, Alec Brown wrote:
> From: Ross Philipson <ross.philipson@oracle.com>
>
> From: Ross Philipson <ross.philipson@oracle.com>
nit: just fix this glitch please :-)
>
> Consolidate TPM1 constants in tpm_command.h and remove duplicate
> constants from tpm1-cmd.c.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
> Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
> ---
> drivers/char/tpm/tpm-buf.c | 1 -
> drivers/char/tpm/tpm1-cmd.c | 14 +-------
> include/keys/trusted_tpm.h | 1 -
> include/linux/tpm.h | 2 ++
> include/linux/tpm_command.h | 43 ++++++++++++++++-------
> security/keys/trusted-keys/trusted_tpm1.c | 1 -
> security/keys/trusted-keys/trusted_tpm2.c | 1 -
> 7 files changed, 33 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-buf.c b/drivers/char/tpm/tpm-buf.c
> index dc882fc9fa9e..4c4f450630df 100644
> --- a/drivers/char/tpm/tpm-buf.c
> +++ b/drivers/char/tpm/tpm-buf.c
> @@ -3,7 +3,6 @@
> * Handling of TPM command and other buffers.
> */
>
> -#include <linux/tpm_command.h>
> #include <linux/module.h>
> #include <linux/tpm.h>
>
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index b49a790f1bd5..664ca1fff2e8 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -22,8 +22,6 @@
>
> #include "tpm.h"
>
> -#define TPM_MAX_ORDINAL 243
> -
> /*
> * Array with one entry per ordinal defining the maximum amount
> * of time the chip could take to return the result. The ordinal
> @@ -308,9 +306,6 @@ unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal)
> return duration;
> }
>
> -#define TPM_ORD_STARTUP 153
> -#define TPM_ST_CLEAR 1
> -
> /**
> * tpm1_startup() - turn on the TPM
> * @chip: TPM chip to use
> @@ -459,7 +454,6 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
> return 0;
> }
>
> -#define TPM_ORD_PCR_EXTEND 20
> int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash,
> const char *log_msg)
> {
> @@ -478,7 +472,6 @@ int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash,
> return rc;
> }
>
> -#define TPM_ORD_GET_CAP 101
> ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> const char *desc, size_t min_cap_length)
> {
> @@ -511,7 +504,6 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> }
> EXPORT_SYMBOL_GPL(tpm1_getcap);
>
> -#define TPM_ORD_GET_RANDOM 70
> struct tpm1_get_random_out {
> __be32 rng_data_len;
> u8 rng_data[TPM_MAX_RNG_DATA];
> @@ -580,13 +572,12 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest, size_t max)
> return rc;
> }
>
> -#define TPM_ORD_PCRREAD 21
> int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf)
> {
> struct tpm_buf buf;
> int rc;
>
> - rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCRREAD);
> + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_READ);
> if (rc)
> return rc;
>
> @@ -609,7 +600,6 @@ int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf)
> return rc;
> }
>
> -#define TPM_ORD_CONTINUE_SELFTEST 83
> /**
> * tpm1_continue_selftest() - run TPM's selftest
> * @chip: TPM chip to use
> @@ -726,8 +716,6 @@ int tpm1_auto_startup(struct tpm_chip *chip)
> return rc;
> }
>
> -#define TPM_ORD_SAVESTATE 152
> -
> /**
> * tpm1_pm_suspend() - pm suspend handler
> * @chip: TPM chip to use.
> diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> index 0fadc6a4f166..3a0fa3bc8454 100644
> --- a/include/keys/trusted_tpm.h
> +++ b/include/keys/trusted_tpm.h
> @@ -3,7 +3,6 @@
> #define __TRUSTED_TPM_H
>
> #include <keys/trusted-type.h>
> -#include <linux/tpm_command.h>
>
> extern struct trusted_key_ops trusted_key_tpm_ops;
>
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index 202da079d500..18dcf0ef46f6 100644
> --- a/include/linux/tpm.h
> +++ b/include/linux/tpm.h
> @@ -25,6 +25,8 @@
> #include <crypto/hash_info.h>
> #include <crypto/aes.h>
>
> +#include "tpm_command.h"
> +
> #define TPM_DIGEST_SIZE 20 /* Max TPM v1.2 PCR size */
>
> #define TPM2_MAX_DIGEST_SIZE SHA512_DIGEST_SIZE
> diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
> index f5c03e9c3913..9a8991b8801d 100644
> --- a/include/linux/tpm_command.h
> +++ b/include/linux/tpm_command.h
> @@ -2,28 +2,45 @@
> #ifndef __LINUX_TPM_COMMAND_H__
> #define __LINUX_TPM_COMMAND_H__
>
> +/************************************************/
> +/* TPM 1 Family Chips */
> +/************************************************/
> +
> /*
> - * TPM Command constants from specifications at
> - * http://www.trustedcomputinggroup.org
> + * TPM 1.2 Main Specification
> + * https://trustedcomputinggroup.org/resource/tpm-main-specification/
> */
>
> +#define TPM_MAX_ORDINAL 243
> +
> /* Command TAGS */
> -#define TPM_TAG_RQU_COMMAND 193
> -#define TPM_TAG_RQU_AUTH1_COMMAND 194
> -#define TPM_TAG_RQU_AUTH2_COMMAND 195
> -#define TPM_TAG_RSP_COMMAND 196
> -#define TPM_TAG_RSP_AUTH1_COMMAND 197
> -#define TPM_TAG_RSP_AUTH2_COMMAND 198
> +enum tpm_command_tags {
> + TPM_TAG_RQU_COMMAND = 193,
> + TPM_TAG_RQU_AUTH1_COMMAND = 194,
> + TPM_TAG_RQU_AUTH2_COMMAND = 195,
> + TPM_TAG_RSP_COMMAND = 196,
> + TPM_TAG_RSP_AUTH1_COMMAND = 197,
> + TPM_TAG_RSP_AUTH2_COMMAND = 198,
> +};
>
> /* Command Ordinals */
> -#define TPM_ORD_GETRANDOM 70
> -#define TPM_ORD_OSAP 11
> -#define TPM_ORD_OIAP 10
> -#define TPM_ORD_SEAL 23
> -#define TPM_ORD_UNSEAL 24
> +enum tpm_command_ordinals {
> + TPM_ORD_CONTINUE_SELFTEST = 83,
> + TPM_ORD_GET_CAP = 101,
> + TPM_ORD_GET_RANDOM = 70,
> + TPM_ORD_PCR_EXTEND = 20,
> + TPM_ORD_PCR_READ = 21,
> + TPM_ORD_OSAP = 11,
> + TPM_ORD_OIAP = 10,
> + TPM_ORD_SAVESTATE = 152,
> + TPM_ORD_SEAL = 23,
> + TPM_ORD_STARTUP = 153,
> + TPM_ORD_UNSEAL = 24,
> +};
>
> /* Other constants */
> #define SRKHANDLE 0x40000000
> #define TPM_NONCE_SIZE 20
> +#define TPM_ST_CLEAR 1
>
> #endif
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 636acb66a4f6..10f79a8c2d35 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -17,7 +17,6 @@
> #include <keys/trusted-type.h>
> #include <linux/key-type.h>
> #include <linux/tpm.h>
> -#include <linux/tpm_command.h>
>
> #include <keys/trusted_tpm.h>
>
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index a7ea4a1c3bed..56eb8e20780a 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -9,7 +9,6 @@
> #include <linux/string.h>
> #include <linux/err.h>
> #include <linux/tpm.h>
> -#include <linux/tpm_command.h>
>
> #include <keys/trusted-type.h>
> #include <keys/trusted_tpm.h>
> --
> 2.47.3
>
I need to compile and test these but yes agree with the idea.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] tpm: fix tpm disabling if NULL name changes
From: Jarkko Sakkinen @ 2026-03-23 5:36 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-integrity
In-Reply-To: <e12b2c091d85ae6bb1f54133c7d4727770f1ee9f.camel@HansenPartnership.com>
On Fri, Mar 13, 2026 at 10:31:03AM -0400, James Bottomley wrote:
> There's a logic error in the earlier fix which means that if the NULL
> name comparison fails, the tpm isn't disabled because rc remains zero.
> Fix this by setting it to an error.
>
> Cc: stable@vger.kernel.org # 6.12
> Fixes: cc7d8594342a ("tpm: Rollback tpm2_load_null()")
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>
> I didn't actually discover this problem until I was trying to do a
> reset attack demo with an updated kernel.
>
> drivers/char/tpm/tpm2-sessions.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-
> sessions.c
> index 3b1cf1ca0420..bd1c0456e775 100644
> --- a/drivers/char/tpm/tpm2-sessions.c
> +++ b/drivers/char/tpm/tpm2-sessions.c
> @@ -961,6 +961,7 @@ static int tpm2_load_null(struct tpm_chip *chip,
> u32 *null_key)
> /* Deduce from the name change TPM interference: */
> dev_err(&chip->dev, "null key integrity check failed\n");
> tpm2_flush_context(chip, tmp_null_key);
> + rc = -ENODEV;
>
> err:
> if (rc) {
> --
> 2.51.0
>
>
Possible to resend (fake ancestor)?
Other than that,
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2026-03-23 5:34 UTC (permalink / raw)
To: Mimi Zohar
Cc: Chris Fenner, linux-integrity, Jonathan McDowell, Eric Biggers,
James Bottomley, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list, Roberto Sassu
In-Reply-To: <acDPCRVx_xO_RhZK@kernel.org>
On Mon, Mar 23, 2026 at 07:26:38AM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 19, 2026 at 10:28:03AM -0400, Mimi Zohar wrote:
> > On Wed, 2026-03-18 at 10:36 -0700, Chris Fenner wrote:
> > > Apologies if my long message derailed this discussion. I meant to
> > > support Mimi's concern here and project a future vision where
> > > TCG_TPM2_HMAC doesn't conflict with other features.
> > >
> > > More concisely, I think that:
> > >
> > > > tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled
> > >
> > > is not a compelling argument for removing TPM as an RNG source,
> > > because TCG_TPM2_HMAC is known to have poor performance already
> > > anyway.
> >
> > Agreed. Thanks, Chris! FYI, we raised concerns about IMA performance with the
> > TPM HMAC and encrypted feature while it was being developed. James had some
> > ideas, at the time, as to how to resolve the performance issue for IMA. Yet it
> > was upstreamed without those changes and with CONFIG_TCG_TPM2_HMAC enabled by
> > default on x86 systems.
> >
> > Jarkko has queued this patch in the "queue" branch, without indicating whether
> > it will eventually be upstreamed or not.
>
> Yes and there's been multiple months of time to comment this and I
> backed up the patch set there, which is not same as applying it.
There's quite many other patches in that patch set also in the queue
branch. This was largeriy past life for me when these comments came.
Really don't understand what is suddenly going on tnh and for one
not that interesting patch.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/2] keys/trusted_keys: clean up debug message logging in the tpm backend
From: Jarkko Sakkinen @ 2026-03-23 5:28 UTC (permalink / raw)
To: Srish Srinivasan
Cc: Nayna Jain, linux-integrity, keyrings, James.Bottomley, zohar,
stefanb, linux-kernel, linux-security-module
In-Reply-To: <21cc6859-1750-4c22-91bb-116620764ca9@linux.ibm.com>
On Tue, Mar 17, 2026 at 08:44:03AM +0530, Srish Srinivasan wrote:
>
> On 3/10/26 4:15 AM, Nayna Jain wrote:
> >
> > On 2/20/26 1:34 PM, Srish Srinivasan wrote:
> > > The TPM trusted-keys backend uses a local TPM_DEBUG guard and pr_info()
> > > for logging debug information.
> > >
> > > Replace pr_info() with pr_debug(), and use KERN_DEBUG for
> > > print_hex_dump().
> > > Remove TPM_DEBUG.
> > >
> > > No functional change intended.
> > There is functional change here. This change allows secret and nonce in
> > the function dump_sess() to be logged to kernel logs when dynamic debug
> > is enabled. Previously, it was possible only in the debug builds and not
> > the production builds at runtime. With this change, it is always there
> > in production build. This can result in possible attack.
>
>
> Hi Jarkko,
> Could you please let us know your thoughts on this one?
>
> And Nayna,
> thanks for bringing this up.
Nayna is absolutely right so I dropped it.
Solution is debatable.
>
> thanks,
> Srish.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2026-03-23 5:26 UTC (permalink / raw)
To: Mimi Zohar
Cc: Chris Fenner, linux-integrity, Jonathan McDowell, Eric Biggers,
James Bottomley, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list, Roberto Sassu
In-Reply-To: <df0a54666d890d5223877e0a0f90ac9082b2d038.camel@linux.ibm.com>
On Thu, Mar 19, 2026 at 10:28:03AM -0400, Mimi Zohar wrote:
> On Wed, 2026-03-18 at 10:36 -0700, Chris Fenner wrote:
> > Apologies if my long message derailed this discussion. I meant to
> > support Mimi's concern here and project a future vision where
> > TCG_TPM2_HMAC doesn't conflict with other features.
> >
> > More concisely, I think that:
> >
> > > tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled
> >
> > is not a compelling argument for removing TPM as an RNG source,
> > because TCG_TPM2_HMAC is known to have poor performance already
> > anyway.
>
> Agreed. Thanks, Chris! FYI, we raised concerns about IMA performance with the
> TPM HMAC and encrypted feature while it was being developed. James had some
> ideas, at the time, as to how to resolve the performance issue for IMA. Yet it
> was upstreamed without those changes and with CONFIG_TCG_TPM2_HMAC enabled by
> default on x86 systems.
>
> Jarkko has queued this patch in the "queue" branch, without indicating whether
> it will eventually be upstreamed or not.
Yes and there's been multiple months of time to comment this and I
backed up the patch set there, which is not same as applying it.
>
> Mimi
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2026-03-23 5:24 UTC (permalink / raw)
To: Mimi Zohar
Cc: Chris Fenner, linux-integrity, Jonathan McDowell, Eric Biggers,
James Bottomley, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list, Roberto Sassu
In-Reply-To: <dca994cd0ed11a262d4022c4984984460ba06a78.camel@linux.ibm.com>
On Thu, Mar 05, 2026 at 10:37:08AM -0500, Mimi Zohar wrote:
> On Tue, 2026-03-03 at 23:32 +0200, Jarkko Sakkinen wrote:
> > On Fri, Feb 20, 2026 at 10:30:26AM -0800, Chris Fenner wrote:
> > > My conclusion about TCG_TPM2_HMAC after [1] and [2] was that
> > > TPM2_TCG_HMAC doesn't (or didn't at the time) actually solve the
> > > threat model it claims to (active interposer adversaries), while
> > > dramatically increasing the cost of many kernel TPM activities beyond
> > > the amount that would have been required to just solve for
> > > passive/bus-sniffer interposer adversaries. The added symmetric crypto
> > > required to secure a TPM transaction is almost not noticeable; the big
> > > performance problem is the re-bootstrapping of the session with ECDH
> > > for every command.
> > >
> > > My primary concern at that time was, essentially, that TCG_TPM2_HMAC
> > > punts on checking that the key that was used to secure the session was
> > > actually resident in a real TPM and not just an interposer adversary.
> > > I wrote up my understanding at
> > > https://www.dlp.rip/decorative-cryptography, for anyone who wants a
> > > long-form opinionated take :).
> > >
> > > Unless I'm wrong, or TCG_TPM2_HMAC has changed dramatically since
> > > August, I don't think "TPM2_TCG_HMAC makes this too costly" is a
> > > compelling reason to make a security decision. (There could be other
> > > reasons to make choices about whether to use the TPM as a source of
> > > randomness in the kernel! This just isn't one IMHO.)
> > >
> > > The version of TCG_TPM2_HMAC that I'd like to see someday would be one
> > > that fully admits that its threat model is only passive interposers,
> > > and sets up one session upon startup and ContextSaves/ContextLoads it
> > > back into the TPM as needed in order to secure parameter encryption
> > > for e.g., GetRandom() and Unseal() calls.
> >
> > Neither agreeing nor disagreeing but this patch set clearly does not
> > move forward and I spent already enough energy for this. For better
> > ideas the patches are available in queue branch.
>
> Jarkko, you totally ignored my comments below. I object to your removing the
> TPM trusted-keys RNG support.
It has not been removed but I can keep the patches still backed
up in a branch, can't I?
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/2] keys/trusted_keys: clean up debug message logging in the tpm backend
From: Jarkko Sakkinen @ 2026-03-23 5:21 UTC (permalink / raw)
To: Nayna Jain
Cc: Srish Srinivasan, linux-integrity, keyrings, James.Bottomley,
zohar, stefanb, linux-kernel, linux-security-module
In-Reply-To: <acDM-hNRThVPRYhq@kernel.org>
On Mon, Mar 23, 2026 at 07:17:51AM +0200, Jarkko Sakkinen wrote:
> On Mon, Mar 09, 2026 at 06:45:23PM -0400, Nayna Jain wrote:
> >
> > On 2/20/26 1:34 PM, Srish Srinivasan wrote:
> > > The TPM trusted-keys backend uses a local TPM_DEBUG guard and pr_info()
> > > for logging debug information.
> > >
> > > Replace pr_info() with pr_debug(), and use KERN_DEBUG for print_hex_dump().
> > > Remove TPM_DEBUG.
> > >
> > > No functional change intended.
> > There is functional change here. This change allows secret and nonce in the
> > function dump_sess() to be logged to kernel logs when dynamic debug is
> > enabled. Previously, it was possible only in the debug builds and not the
> > production builds at runtime. With this change, it is always there in
> > production build. This can result in possible attack.
>
> Good catch, thank you. It's in my master branch still (not in -next).
>
> TPM_DEBUG should be removed in all cases. If you really want to read
> a secret, use tracing tools.
>
> This only proves that the print should exist or should be a constant
> value, or overwritten same length value.
I dropped the current patches but yeah, a comment "do not touch this,
could be poisonous" won't be an acceptable way to address this.
If you want "some" debug information you can always put F-string or
0-string of same length, so there's options.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 1/2] keys/trusted_keys: clean up debug message logging in the tpm backend
From: Jarkko Sakkinen @ 2026-03-23 5:17 UTC (permalink / raw)
To: Nayna Jain
Cc: Srish Srinivasan, linux-integrity, keyrings, James.Bottomley,
zohar, stefanb, linux-kernel, linux-security-module
In-Reply-To: <7f8b8478-5cd8-4d97-bfd0-341fd5cf10f9@linux.ibm.com>
On Mon, Mar 09, 2026 at 06:45:23PM -0400, Nayna Jain wrote:
>
> On 2/20/26 1:34 PM, Srish Srinivasan wrote:
> > The TPM trusted-keys backend uses a local TPM_DEBUG guard and pr_info()
> > for logging debug information.
> >
> > Replace pr_info() with pr_debug(), and use KERN_DEBUG for print_hex_dump().
> > Remove TPM_DEBUG.
> >
> > No functional change intended.
> There is functional change here. This change allows secret and nonce in the
> function dump_sess() to be logged to kernel logs when dynamic debug is
> enabled. Previously, it was possible only in the debug builds and not the
> production builds at runtime. With this change, it is always there in
> production build. This can result in possible attack.
Good catch, thank you. It's in my master branch still (not in -next).
TPM_DEBUG should be removed in all cases. If you really want to read
a secret, use tracing tools.
This only proves that the print should exist or should be a constant
value, or overwritten same length value.
> Instead of doing this change, I think add a comment to prevent this sort of
> change in the future.
>
> Thanks & Regards,
>
> - Nayna
>
> >
> > Signed-off-by: Srish Srinivasan <ssrish@linux.ibm.com>
> > Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
> > ---
> > security/keys/trusted-keys/trusted_tpm1.c | 40 +++++++----------------
> > 1 file changed, 12 insertions(+), 28 deletions(-)
> >
> > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > index c865c97aa1b4..216caef97ffc 100644
> > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > @@ -46,28 +46,25 @@ enum {
> > SRK_keytype = 4
> > };
> > -#define TPM_DEBUG 0
> > -
> > -#if TPM_DEBUG
> > static inline void dump_options(struct trusted_key_options *o)
> > {
> > - pr_info("sealing key type %d\n", o->keytype);
> > - pr_info("sealing key handle %0X\n", o->keyhandle);
> > - pr_info("pcrlock %d\n", o->pcrlock);
> > - pr_info("pcrinfo %d\n", o->pcrinfo_len);
> > - print_hex_dump(KERN_INFO, "pcrinfo ", DUMP_PREFIX_NONE,
> > + pr_debug("sealing key type %d\n", o->keytype);
> > + pr_debug("sealing key handle %0X\n", o->keyhandle);
> > + pr_debug("pcrlock %d\n", o->pcrlock);
> > + pr_debug("pcrinfo %d\n", o->pcrinfo_len);
> > + print_hex_dump(KERN_DEBUG, "pcrinfo ", DUMP_PREFIX_NONE,
> > 16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> > }
> > static inline void dump_sess(struct osapsess *s)
> > {
> > - print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> > + print_hex_dump(KERN_DEBUG, "trusted-key: handle ", DUMP_PREFIX_NONE,
> > 16, 1, &s->handle, 4, 0);
> > - pr_info("secret:\n");
> > - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> > + pr_debug("secret:\n");
> > + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> > 16, 1, &s->secret, SHA1_DIGEST_SIZE, 0);
> > - pr_info("trusted-key: enonce:\n");
> > - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE,
> > + pr_debug("trusted-key: enonce:\n");
> > + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE,
> > 16, 1, &s->enonce, SHA1_DIGEST_SIZE, 0);
> > }
> > @@ -75,23 +72,10 @@ static inline void dump_tpm_buf(unsigned char *buf)
> > {
> > int len;
> > - pr_info("\ntpm buffer\n");
> > + pr_debug("\ntpm buffer\n");
> > len = LOAD32(buf, TPM_SIZE_OFFSET);
> > - print_hex_dump(KERN_INFO, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> > -}
> > -#else
> > -static inline void dump_options(struct trusted_key_options *o)
> > -{
> > -}
> > -
> > -static inline void dump_sess(struct osapsess *s)
> > -{
> > -}
> > -
> > -static inline void dump_tpm_buf(unsigned char *buf)
> > -{
> > + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_NONE, 16, 1, buf, len, 0);
> > }
> > -#endif
> > static int TSS_rawhmac(unsigned char *digest, const unsigned char *key,
> > unsigned int keylen, ...)
BR, Jarkko
^ permalink raw reply
* [PATCH] tpm: i2c: atmel: fix block comment formatting
From: Ethan Luna @ 2026-03-22 19:30 UTC (permalink / raw)
To: peterhuewe, jarkko
Cc: jgg, nicolas.ferre, claudiu.beznea, linux-integrity,
linux-arm-kernel, linux-kernel
Multiple block comments in tpm_i2c_atmel.c placed the closing '*/' on the
same line as the comment text. This violates the kernel's preferred
comment style, which requires the closing delimiter to appear on it's
line.
Fix the formatting to improve readability and resolve checkpatch
warnings.
Signed-off-by: Ethan Luna <trunixcodes@zohomail.com>
---
drivers/char/tpm/tpm_i2c_atmel.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index 4f229656a8e2..702b3c9191dc 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -33,7 +33,8 @@ struct priv_data {
size_t len;
/* This is the amount we read on the first try. 25 was chosen to fit a
* fair number of read responses in the buffer so a 2nd retry can be
- * avoided in small message cases. */
+ * avoided in small message cases.
+ */
u8 buffer[sizeof(struct tpm_header) + 25];
};
@@ -58,7 +59,9 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz,
if (status < 0)
return status;
- /* The upper layer does not support incomplete sends. */
+ /*
+ * The upper layer does not support incomplete sends.
+ */
if (status != len)
return -E2BIG;
@@ -78,7 +81,8 @@ static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)
/* Get the message size from the message header, if we didn't get the
* whole message in read_status then we need to re-read the
- * message. */
+ * message.
+ */
expected_len = be32_to_cpu(hdr->length);
if (expected_len > count)
return -ENOMEM;
@@ -113,13 +117,15 @@ static u8 i2c_atmel_read_status(struct tpm_chip *chip)
/* The TPM fails the I2C read until it is ready, so we do the entire
* transfer here and buffer it locally. This way the common code can
- * properly handle the timeouts. */
+ * properly handle the timeouts.
+ */
priv->len = 0;
memset(priv->buffer, 0, sizeof(priv->buffer));
/* Once the TPM has completed the command the command remains readable
- * until another command is issued. */
+ * until another command is issued.
+ */
rc = i2c_master_recv(client, priv->buffer, sizeof(priv->buffer));
dev_dbg(&chip->dev,
"%s: sts=%d", __func__, rc);
@@ -174,7 +180,8 @@ static int i2c_atmel_probe(struct i2c_client *client)
/* There is no known way to probe for this device, and all version
* information seems to be read via TPM commands. Thus we rely on the
- * TPM startup process in the common code to detect the device. */
+ * TPM startup process in the common code to detect the device.
+ */
return tpm_chip_register(chip);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ima: abort file hash computation on fatal signal
From: Eric Biggers @ 2026-03-22 14:17 UTC (permalink / raw)
To: Shigeru Yoshida
Cc: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn,
syzbot+6ed94e81a1492fe1d512, linux-integrity,
linux-security-module, linux-kernel
In-Reply-To: <20260322111019.2815601-1-syoshida@redhat.com>
On Sun, Mar 22, 2026 at 08:10:19PM +0900, Shigeru Yoshida wrote:
> ima_calc_file_hash_atfm() and ima_calc_file_hash_tfm() compute a hash
> over the entire file contents without checking for pending fatal
> signals. When a very large file is being hashed during mmap (via
> ima_file_mmap), the computation can take an extended period. If a
> coredump is initiated by another thread in the same thread group during
> this time, the dumper thread waits in coredump_wait() for all other
> threads to exit. However, the hashing thread cannot exit until the hash
> loop completes, resulting in a hung task.
>
> Add fatal_signal_pending() checks to both the ahash and shash file
> hashing loops so that the computation is aborted promptly when SIGKILL
> is received.
>
> Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
> Reported-by: syzbot+6ed94e81a1492fe1d512@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=6ed94e81a1492fe1d512
> Tested-by: syzbot+6ed94e81a1492fe1d512@syzkaller.appspotmail.com
> Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
> ---
> security/integrity/ima/ima_crypto.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
> index aff61643415d..7b721b9c944f 100644
> --- a/security/integrity/ima/ima_crypto.c
> +++ b/security/integrity/ima/ima_crypto.c
> @@ -17,6 +17,7 @@
> #include <linux/crypto.h>
> #include <linux/scatterlist.h>
> #include <linux/err.h>
> +#include <linux/sched/signal.h>
> #include <linux/slab.h>
> #include <crypto/hash.h>
>
> @@ -416,6 +417,12 @@ static int ima_calc_file_hash_atfm(struct file *file,
>
> if (rbuf[1])
> active = !active; /* swap buffers, if we use two */
> +
> + if (fatal_signal_pending(current)) {
> + ahash_wait(ahash_rc, &wait);
> + rc = -EINTR;
> + goto out3;
> + }
I think you'll need to rebase onto
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git/log/?h=next-integrity
since there is a patch queued up that removes ima_calc_file_hash_atfm().
So only ima_calc_file_hash_tfm() will need to be updated.
- Eric
^ permalink raw reply
* [PATCH] ima: abort file hash computation on fatal signal
From: Shigeru Yoshida @ 2026-03-22 11:10 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn
Cc: Shigeru Yoshida, syzbot+6ed94e81a1492fe1d512, linux-integrity,
linux-security-module, linux-kernel
ima_calc_file_hash_atfm() and ima_calc_file_hash_tfm() compute a hash
over the entire file contents without checking for pending fatal
signals. When a very large file is being hashed during mmap (via
ima_file_mmap), the computation can take an extended period. If a
coredump is initiated by another thread in the same thread group during
this time, the dumper thread waits in coredump_wait() for all other
threads to exit. However, the hashing thread cannot exit until the hash
loop completes, resulting in a hung task.
Add fatal_signal_pending() checks to both the ahash and shash file
hashing loops so that the computation is aborted promptly when SIGKILL
is received.
Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Reported-by: syzbot+6ed94e81a1492fe1d512@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=6ed94e81a1492fe1d512
Tested-by: syzbot+6ed94e81a1492fe1d512@syzkaller.appspotmail.com
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
---
security/integrity/ima/ima_crypto.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/security/integrity/ima/ima_crypto.c b/security/integrity/ima/ima_crypto.c
index aff61643415d..7b721b9c944f 100644
--- a/security/integrity/ima/ima_crypto.c
+++ b/security/integrity/ima/ima_crypto.c
@@ -17,6 +17,7 @@
#include <linux/crypto.h>
#include <linux/scatterlist.h>
#include <linux/err.h>
+#include <linux/sched/signal.h>
#include <linux/slab.h>
#include <crypto/hash.h>
@@ -416,6 +417,12 @@ static int ima_calc_file_hash_atfm(struct file *file,
if (rbuf[1])
active = !active; /* swap buffers, if we use two */
+
+ if (fatal_signal_pending(current)) {
+ ahash_wait(ahash_rc, &wait);
+ rc = -EINTR;
+ goto out3;
+ }
}
/* wait for the last update request to complete */
rc = ahash_wait(ahash_rc, &wait);
@@ -491,6 +498,10 @@ static int ima_calc_file_hash_tfm(struct file *file,
rc = crypto_shash_update(shash, rbuf, rbuf_len);
if (rc)
break;
+ if (fatal_signal_pending(current)) {
+ rc = -EINTR;
+ break;
+ }
}
kfree(rbuf);
out:
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 4/4] tpm: Move TPM common base definitions to the command header
From: kernel test robot @ 2026-03-22 2:00 UTC (permalink / raw)
To: Alec Brown, linux-kernel, linux-integrity, jarkko
Cc: oe-kbuild-all, peterhuewe, jarkko.sakkinen, jgg, ross.philipson,
dpsmith, daniel.kiper, kanth.ghatraju, trenchboot-devel, ardb,
alec.r.brown
In-Reply-To: <20260317160613.2899129-5-alec.r.brown@oracle.com>
Hi Alec,
kernel test robot noticed the following build warnings:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on char-misc/char-misc-next char-misc/char-misc-linus linus/master v7.0-rc4 next-20260320]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Alec-Brown/tpm-Initial-step-to-reorganize-TPM-public-headers/20260322-021741
base: char-misc/char-misc-testing
patch link: https://lore.kernel.org/r/20260317160613.2899129-5-alec.r.brown%40oracle.com
patch subject: [PATCH 4/4] tpm: Move TPM common base definitions to the command header
config: arm-randconfig-r132-20260322 (https://download.01.org/0day-ci/archive/20260322/202603220920.LNzslwgU-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 4abb927bacf37f18f6359a41639a6d1b3bffffb5)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260322/202603220920.LNzslwgU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603220920.LNzslwgU-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/char/tpm/tpm-dev-common.c:19:
In file included from drivers/char/tpm/tpm.h:29:
include/linux/tpm_eventlog.h:167:6: warning: variable 'mapping_size' set but not used [-Wunused-but-set-variable]
167 | int mapping_size;
| ^
In file included from drivers/char/tpm/tpm-dev-common.c:19:
In file included from drivers/char/tpm/tpm.h:28:
In file included from include/linux/tpm.h:28:
>> include/linux/tpm_command.h:517:2: warning: field within 'struct tpm_header' is less aligned than 'union tpm_header::(anonymous at include/linux/tpm_command.h:517:2)' and is usually due to 'struct tpm_header' being packed, which can lead to unaligned accesses [-Wunaligned-access]
517 | union {
| ^
2 warnings generated.
--
In file included from drivers/char/tpm/tpm-buf.c:7:
In file included from include/linux/tpm.h:28:
>> include/linux/tpm_command.h:517:2: warning: field within 'struct tpm_header' is less aligned than 'union tpm_header::(anonymous at include/linux/tpm_command.h:517:2)' and is usually due to 'struct tpm_header' being packed, which can lead to unaligned accesses [-Wunaligned-access]
517 | union {
| ^
1 warning generated.
vim +517 include/linux/tpm_command.h
513
514 struct tpm_header {
515 __be16 tag;
516 __be32 length;
> 517 union {
518 __be32 ordinal;
519 __be32 return_code;
520 };
521 } __packed;
522
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 0/8] module: Move 'struct module_signature' to UAPI
From: Nicolas Schier @ 2026-03-20 20:06 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: David Howells, David Woodhouse, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Paul Moore, James Morris, Serge E. Hallyn,
Nathan Chancellor, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Shuah Khan, keyrings, linux-kernel,
linux-modules, linux-s390, linux-integrity, linux-security-module,
linux-kbuild, bpf, linux-kselftest
In-Reply-To: <20260305-module-signature-uapi-v3-0-92f45ea6028c@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]
On Thu, Mar 05, 2026 at 10:31:36AM +0100, Thomas Weißschuh wrote:
> This structure definition is used outside the kernel proper.
> For example in kmod and the kernel build environment.
>
> To allow reuse, move it to a new UAPI header.
>
> While it is not a true UAPI, it is a common practice to have
> non-UAPI interface definitions in the kernel's UAPI headers.
>
> This came up as part of my CONFIG_MODULE_HASHES series [0].
> But it is useful on its own and so we get it out of the way.
>
> [0] https://lore.kernel.org/lkml/aZ3OfJJSJgfOb0rJ@levanger/
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> Changes in v3:
> - Also adapt the include path for the custom sign-file rule in the bpf selftests.
> (My manual run of BPF CI still fails, due to an BUG() on s390,
> I don't see how this is due to this patch)
> - Link to v2: https://lore.kernel.org/r/20260305-module-signature-uapi-v2-0-dc4d81129dee@linutronix.de
>
> Changes in v2:
> - Drop spurious definition of MODULE_SIGNATURE_TYPE_MERKLE.
> - s/modules/module/ in two patch subjects.
> - Pick up review tags.
> - Link to v1: https://lore.kernel.org/r/20260302-module-signature-uapi-v1-0-207d955e0d69@linutronix.de
>
> ---
> Thomas Weißschuh (8):
> extract-cert: drop unused definition of PKEY_ID_PKCS7
> module: Drop unused signature types
> module: Give 'enum pkey_id_type' a more specific name
> module: Give MODULE_SIG_STRING a more descriptive name
> module: Move 'struct module_signature' to UAPI
> tools uapi headers: add linux/module_signature.h
> sign-file: use 'struct module_signature' from the UAPI headers
> selftests/bpf: verify_pkcs7_sig: Use 'struct module_signature' from the UAPI headers
>
> arch/s390/kernel/machine_kexec_file.c | 6 ++--
> certs/extract-cert.c | 2 --
> include/linux/module_signature.h | 30 +---------------
> include/uapi/linux/module_signature.h | 41 ++++++++++++++++++++++
> kernel/module/signing.c | 4 +--
> kernel/module_signature.c | 2 +-
> scripts/Makefile | 1 +
> scripts/sign-file.c | 19 +++-------
> security/integrity/ima/ima_modsig.c | 6 ++--
> tools/include/uapi/linux/module_signature.h | 41 ++++++++++++++++++++++
> tools/testing/selftests/bpf/Makefile | 1 +
> .../selftests/bpf/prog_tests/verify_pkcs7_sig.c | 28 ++-------------
> 12 files changed, 101 insertions(+), 80 deletions(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260302-module-signature-uapi-61fa80b1e2bb
>
Thanks for these patches!
For the whole series:
Reviewed-by: Nicolas Schier <nsc@kernel.org>
--
Nicolas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: Roberto Sassu @ 2026-03-20 17:26 UTC (permalink / raw)
To: steven chen, Mimi Zohar, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu
In-Reply-To: <8f66014c-d7c8-4a33-be7b-cfd945af4a3a@linux.microsoft.com>
On Fri, 2026-03-20 at 10:24 -0700, steven chen wrote:
> On 3/20/2026 10:10 AM, Roberto Sassu wrote:
> > On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote:
> > > On 3/20/2026 5:41 AM, Mimi Zohar wrote:
> > > > On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
> > > >
> > > > > > - Support for deleting N measurement records (and pre-pending the remaining
> > > > > > measurement records)
> > > > > Is there any problem to bring work of "stage" step together to the
> > > > > deletion step?
> > > > >
> > > > > "Trim N" method does everything that "staged" method can do, right?
> > > > > what's the "stage" method can do but "trim N" method can't do?
> > > > >
> > > > > in user space, if in "staged" state, no other user space agent can
> > > > > access the IMA measure list, right?
> > > > >
> > > > > Could you explain the benefit of bringing the "stage" step?
> > > > The performance improvement is because "staging" the IMA measurement list takes
> > > > the lock in order to move the measurement list pointer and then releases it.
> > > > New measurements can then be appended to a new measurement list. Deleting
> > > > records is done without taking the lock to walk the staged measurement list.
> > > >
> > > > Without staging the measurement list, walking the measurement list to trim N
> > > > records requires taking and holding the lock. The performance is dependent on
> > > > the size of the measurement list.
> > > >
> > > > Your question isn't really about "staging" the measurement list records, but
> > > > requiring a userspace signal to delete them. To answer that question, deleting
> > > > N records (third patch) could imply staging all the measurement records and
> > > > immediately deleting N records without an explicit userspace signal.
> > > >
> > > > I expect the requested "documentation" patch will provide the motivation for the
> > > > delayed deletion of the measurement list.
> > > >
> > > > Mimi
> > > "Staging" is great on reducing kernel IMA measurement list locking time.
> > >
> > > How about just do "stage N" entries and then delete the staged list in
> > > one shot?
> > > It means merge two APIs into one API
> > > int ima_queue_stage(void)
> > > int ima_queue_delete_staged(unsigned long req_value)
> > >
> > > The kernel lock time will be the same. And user space lock time will be
> > > reduced.
> > It is not the same. The walk on the staged list is done without holding
> > ima_extend_list_mutex.
> >
> > Roberto
>
> Is it possible to merge two APIs work into one API?
> int ima_queue_stage(void)
> int ima_queue_delete_staged(unsigned long req_value)
It will be done transparently for the user. IMA will call both
functions for the same securityfs write.
Roberto
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: steven chen @ 2026-03-20 17:40 UTC (permalink / raw)
To: Roberto Sassu, Mimi Zohar, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu
In-Reply-To: <a523c0cf05e10838bf08e4d2e9a05df402f4c9b0.camel@huaweicloud.com>
On 3/20/2026 10:26 AM, Roberto Sassu wrote:
> On Fri, 2026-03-20 at 10:24 -0700, steven chen wrote:
>> On 3/20/2026 10:10 AM, Roberto Sassu wrote:
>>> On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote:
>>>> On 3/20/2026 5:41 AM, Mimi Zohar wrote:
>>>>> On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
>>>>>
>>>>>>> - Support for deleting N measurement records (and pre-pending the remaining
>>>>>>> measurement records)
>>>>>> Is there any problem to bring work of "stage" step together to the
>>>>>> deletion step?
>>>>>>
>>>>>> "Trim N" method does everything that "staged" method can do, right?
>>>>>> what's the "stage" method can do but "trim N" method can't do?
>>>>>>
>>>>>> in user space, if in "staged" state, no other user space agent can
>>>>>> access the IMA measure list, right?
>>>>>>
>>>>>> Could you explain the benefit of bringing the "stage" step?
>>>>> The performance improvement is because "staging" the IMA measurement list takes
>>>>> the lock in order to move the measurement list pointer and then releases it.
>>>>> New measurements can then be appended to a new measurement list. Deleting
>>>>> records is done without taking the lock to walk the staged measurement list.
>>>>>
>>>>> Without staging the measurement list, walking the measurement list to trim N
>>>>> records requires taking and holding the lock. The performance is dependent on
>>>>> the size of the measurement list.
>>>>>
>>>>> Your question isn't really about "staging" the measurement list records, but
>>>>> requiring a userspace signal to delete them. To answer that question, deleting
>>>>> N records (third patch) could imply staging all the measurement records and
>>>>> immediately deleting N records without an explicit userspace signal.
>>>>>
>>>>> I expect the requested "documentation" patch will provide the motivation for the
>>>>> delayed deletion of the measurement list.
>>>>>
>>>>> Mimi
>>>> "Staging" is great on reducing kernel IMA measurement list locking time.
>>>>
>>>> How about just do "stage N" entries and then delete the staged list in
>>>> one shot?
>>>> It means merge two APIs into one API
>>>> int ima_queue_stage(void)
>>>> int ima_queue_delete_staged(unsigned long req_value)
>>>>
>>>> The kernel lock time will be the same. And user space lock time will be
>>>> reduced.
>>> It is not the same. The walk on the staged list is done without holding
>>> ima_extend_list_mutex.
>>>
>>> Roberto
>> Is it possible to merge two APIs work into one API?
>> int ima_queue_stage(void)
>> int ima_queue_delete_staged(unsigned long req_value)
> It will be done transparently for the user. IMA will call both
> functions for the same securityfs write.
>
> Roberto
If merge two APIs into one API, it will reduce user space measurement
list lock time.
Thanks,
Steven
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: Roberto Sassu @ 2026-03-20 17:10 UTC (permalink / raw)
To: steven chen, Mimi Zohar, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu
In-Reply-To: <c9258708-2db2-4c08-998f-e67a681781da@linux.microsoft.com>
On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote:
> On 3/20/2026 5:41 AM, Mimi Zohar wrote:
> > On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
> >
> > > > - Support for deleting N measurement records (and pre-pending the remaining
> > > > measurement records)
> > > Is there any problem to bring work of "stage" step together to the
> > > deletion step?
> > >
> > > "Trim N" method does everything that "staged" method can do, right?
> > > what's the "stage" method can do but "trim N" method can't do?
> > >
> > > in user space, if in "staged" state, no other user space agent can
> > > access the IMA measure list, right?
> > >
> > > Could you explain the benefit of bringing the "stage" step?
> > The performance improvement is because "staging" the IMA measurement list takes
> > the lock in order to move the measurement list pointer and then releases it.
> > New measurements can then be appended to a new measurement list. Deleting
> > records is done without taking the lock to walk the staged measurement list.
> >
> > Without staging the measurement list, walking the measurement list to trim N
> > records requires taking and holding the lock. The performance is dependent on
> > the size of the measurement list.
> >
> > Your question isn't really about "staging" the measurement list records, but
> > requiring a userspace signal to delete them. To answer that question, deleting
> > N records (third patch) could imply staging all the measurement records and
> > immediately deleting N records without an explicit userspace signal.
> >
> > I expect the requested "documentation" patch will provide the motivation for the
> > delayed deletion of the measurement list.
> >
> > Mimi
>
> "Staging" is great on reducing kernel IMA measurement list locking time.
>
> How about just do "stage N" entries and then delete the staged list in
> one shot?
> It means merge two APIs into one API
> int ima_queue_stage(void)
> int ima_queue_delete_staged(unsigned long req_value)
>
> The kernel lock time will be the same. And user space lock time will be
> reduced.
It is not the same. The walk on the staged list is done without holding
ima_extend_list_mutex.
Roberto
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: steven chen @ 2026-03-20 17:24 UTC (permalink / raw)
To: Roberto Sassu, Mimi Zohar, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <332fc1447c03893988620189a40501cccaa8b4c5.camel@huaweicloud.com>
On 3/20/2026 10:10 AM, Roberto Sassu wrote:
> On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote:
>> On 3/20/2026 5:41 AM, Mimi Zohar wrote:
>>> On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
>>>
>>>>> - Support for deleting N measurement records (and pre-pending the remaining
>>>>> measurement records)
>>>> Is there any problem to bring work of "stage" step together to the
>>>> deletion step?
>>>>
>>>> "Trim N" method does everything that "staged" method can do, right?
>>>> what's the "stage" method can do but "trim N" method can't do?
>>>>
>>>> in user space, if in "staged" state, no other user space agent can
>>>> access the IMA measure list, right?
>>>>
>>>> Could you explain the benefit of bringing the "stage" step?
>>> The performance improvement is because "staging" the IMA measurement list takes
>>> the lock in order to move the measurement list pointer and then releases it.
>>> New measurements can then be appended to a new measurement list. Deleting
>>> records is done without taking the lock to walk the staged measurement list.
>>>
>>> Without staging the measurement list, walking the measurement list to trim N
>>> records requires taking and holding the lock. The performance is dependent on
>>> the size of the measurement list.
>>>
>>> Your question isn't really about "staging" the measurement list records, but
>>> requiring a userspace signal to delete them. To answer that question, deleting
>>> N records (third patch) could imply staging all the measurement records and
>>> immediately deleting N records without an explicit userspace signal.
>>>
>>> I expect the requested "documentation" patch will provide the motivation for the
>>> delayed deletion of the measurement list.
>>>
>>> Mimi
>> "Staging" is great on reducing kernel IMA measurement list locking time.
>>
>> How about just do "stage N" entries and then delete the staged list in
>> one shot?
>> It means merge two APIs into one API
>> int ima_queue_stage(void)
>> int ima_queue_delete_staged(unsigned long req_value)
>>
>> The kernel lock time will be the same. And user space lock time will be
>> reduced.
> It is not the same. The walk on the staged list is done without holding
> ima_extend_list_mutex.
>
> Roberto
Is it possible to merge two APIs work into one API?
int ima_queue_stage(void)
int ima_queue_delete_staged(unsigned long req_value)
Thank,
Steven
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: steven chen @ 2026-03-20 16:58 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <ffe1d4645a66a690892163be8e16c4b5d24a690d.camel@linux.ibm.com>
On 3/20/2026 5:41 AM, Mimi Zohar wrote:
> On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
>
>>> - Support for deleting N measurement records (and pre-pending the remaining
>>> measurement records)
>> Is there any problem to bring work of "stage" step together to the
>> deletion step?
>>
>> "Trim N" method does everything that "staged" method can do, right?
>> what's the "stage" method can do but "trim N" method can't do?
>>
>> in user space, if in "staged" state, no other user space agent can
>> access the IMA measure list, right?
>>
>> Could you explain the benefit of bringing the "stage" step?
> The performance improvement is because "staging" the IMA measurement list takes
> the lock in order to move the measurement list pointer and then releases it.
> New measurements can then be appended to a new measurement list. Deleting
> records is done without taking the lock to walk the staged measurement list.
>
> Without staging the measurement list, walking the measurement list to trim N
> records requires taking and holding the lock. The performance is dependent on
> the size of the measurement list.
>
> Your question isn't really about "staging" the measurement list records, but
> requiring a userspace signal to delete them. To answer that question, deleting
> N records (third patch) could imply staging all the measurement records and
> immediately deleting N records without an explicit userspace signal.
>
> I expect the requested "documentation" patch will provide the motivation for the
> delayed deletion of the measurement list.
>
> Mimi
"Staging" is great on reducing kernel IMA measurement list locking time.
How about just do "stage N" entries and then delete the staged list in
one shot?
It means merge two APIs into one API
int ima_queue_stage(void)
int ima_queue_delete_staged(unsigned long req_value)
The kernel lock time will be the same. And user space lock time will be
reduced.
Thanks,
Steven
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: Mimi Zohar @ 2026-03-20 12:41 UTC (permalink / raw)
To: steven chen, Roberto Sassu, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu
In-Reply-To: <25e0a273-9044-4e0d-9812-0171ec99e1b7@linux.microsoft.com>
On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
> > - Support for deleting N measurement records (and pre-pending the remaining
> > measurement records)
>
> Is there any problem to bring work of "stage" step together to the
> deletion step?
>
> "Trim N" method does everything that "staged" method can do, right?
> what's the "stage" method can do but "trim N" method can't do?
>
> in user space, if in "staged" state, no other user space agent can
> access the IMA measure list, right?
>
> Could you explain the benefit of bringing the "stage" step?
The performance improvement is because "staging" the IMA measurement list takes
the lock in order to move the measurement list pointer and then releases it.
New measurements can then be appended to a new measurement list. Deleting
records is done without taking the lock to walk the staged measurement list.
Without staging the measurement list, walking the measurement list to trim N
records requires taking and holding the lock. The performance is dependent on
the size of the measurement list.
Your question isn't really about "staging" the measurement list records, but
requiring a userspace signal to delete them. To answer that question, deleting
N records (third patch) could imply staging all the measurement records and
immediately deleting N records without an explicit userspace signal.
I expect the requested "documentation" patch will provide the motivation for the
delayed deletion of the measurement list.
Mimi
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: steven chen @ 2026-03-19 21:31 UTC (permalink / raw)
To: Mimi Zohar, Roberto Sassu, corbet, skhan, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <587e11bf4d29552bbbfc029f716146e8ebfca1eb.camel@linux.ibm.com>
On 3/17/2026 2:03 PM, Mimi Zohar wrote:
> Hi Roberto,
>
> On Wed, 2026-03-11 at 18:19 +0100, Roberto Sassu wrote:
>> From: Roberto Sassu <roberto.sassu@huawei.com>
>>
>> Introduce the ability of staging the IMA measurement list for deletion.
>> Staging means moving the current content of the measurement list to a
>> separate location, and allowing users to read and delete it. This causes
>> the measurement list to be atomically truncated before new measurements can
>> be added.
> I really like this design of atomically moving and subsequently deleting the
> measurement list. However this is a solution, not the motivation for the patch.
> Please include the motivation for the patch, before describing the solution.
>
>> Staging can be done only once at a time. In the event of kexec(),
>> staging is reverted and staged entries will be carried over to the new
>> kernel.
>> Staged measurements can be deleted entirely, or partially, with the
>> non-deleted ones added back to the IMA measurements list.
> This patch description is really long, which is an indication that the patch
> needs to be split up. Adding support for partially deleting the measurement
> list records, by prepending the remaining measurement records, should be a
> separate patch.
>
>> This allows the
>> remote attestation agents to easily separate the measurements that where
>> verified (staged and deleted) from those that weren't due to the race
>> between taking a TPM quote and reading the measurements list.
>>
>> User space is responsible to concatenate the staged IMA measurements list
>> portions (excluding the measurements added back to the IMA measurements
>> list) following the temporal order in which the operations were done,
>> together with the current measurement list. Then, it can send the collected
>> data to the remote verifiers.
> This belongs in a Documentation patch.
>
>> The benefit of staging and deleting is the ability to free precious kernel
>> memory,
> This is the motivation for the patch.
>
>> in exchange of delegating user space to reconstruct the full
>> measurement list from the chunks. No trust needs to be given to user space,
>> since the integrity of the measurement list is protected by the TPM.
> Agreed the measurement list, itself, is protected by the TPM. However, relying
> on userspace to reassemble the chunks is another concern. Support for staging
> and deleting the measurement list should be configurable. Defining a Kconfig
> should be part of this initial patch.
>
>> By default, staging the measurements list does not alter the hash table.
>> When staging and deleting are done, IMA is still able to detect collisions
>> on the staged and later deleted measurement entries, by keeping the entry
>> digests (only template data are freed).
>>
>> However, since during the measurements list serialization only the SHA1
>> digest is passed, and since there are no template data to recalculate the
>> other digests from, the hash table is currently not populated with digests
>> from staged/deleted entries after kexec().
>>
>> Introduce the new kernel option ima_flush_htable to decide whether or not
>> the digests of staged measurement entries are flushed from the hash table,
>> when they are deleted. Flushing the hash table is supported only when
>> deleting all the staged measurements, since in that case the old hash table
>> can be quickly swapped with a blank one (otherwise entries would have to be
>> removed one by one for partial deletion).
> Allowing the hash table to be deleted would be an example of another patch.
>
>> Then, introduce ascii_runtime_measurements_<algo>_staged and
>> binary_runtime_measurements_<algo>_staged interfaces to stage and delete
>> the measurements. Use 'echo A > <IMA interface>' and
>> 'echo D > <IMA interface>' to respectively stage and delete the entire
>> measurements list. Use 'echo N > <IMA interface>', with N between 1 and
>> ULONG_MAX - 1, to delete the selected staged portion of the measurements
>> list.
>>
>> The ima_measure_users counter (protected by the ima_measure_mutex mutex)
>> has been introduced to protect access to the measurements list and the
>> staged part. The open method of all the measurement interfaces has been
>> extended to allow only one writer at a time or, in alternative, multiple
>> readers. The write permission is used to stage and delete the measurements,
>> the read permission to read them. Write requires also the CAP_SYS_ADMIN
>> capability.
> Yes, this is part of the initial patch that adds support for staging the
> measurement list.
>
>> Finally, introduce the binary_lists enum and make binary_runtime_size
>> and ima_num_entries as arrays, to keep track of their values for the
>> current IMA measurements list (BINARY), current list plus staged
>> measurements (BINARY_STAGED) and the cumulative list since IMA
>> initialization (BINARY_FULL).
>>
>> Use BINARY in ima_show_measurements_count(), BINARY_STAGED in
>> ima_add_kexec_buffer() and BINARY_FULL in ima_measure_kexec_event().
>>
>> It should be noted that the BINARY_FULL counter is not passed through
>> kexec. Thus, the number of entries included in the kexec critical data
>> records refers to the entries since the previous kexec records.
>>
>> Note: This code derives from the Alt-IMA Huawei project, whose license is
>> GPL-2.0 OR MIT.
>>
>> Link: https://github.com/linux-integrity/linux/issues/1
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> The design looks good. As I mentioned above, this patch description is quite
> long, which is an indication that the patch needs to be split up. One method of
> breaking it up would be:
>
> - (Basic) support for staging measurements for deletion (based on a Kconfig)
> - Support for removing the hash table
Great work on performance improvement and hash table redesign.
If update the following "Trim N" method patch with your current patch
lock time performance
improvement plus the hash table change, "Trim N" method can do the same
kernel
measurement list lock time as staged method do, right?
https://lore.kernel.org/linux-integrity/20260205235849.7086-1-chenste@linux.microsoft.com/
> - Support for deleting N measurement records (and pre-pending the remaining
> measurement records)
Is there any problem to bring work of "stage" step together to the
deletion step?
"Trim N" method does everything that "staged" method can do, right?
what's the "stage"
method can do but "trim N" method can't do?
in user space, if in "staged" state, no other user space agent can
access the IMA measure list, right?
Could you explain the benefit of bringing the "stage" step?
Thanks,
Steven
> - Adding documentation
>
> thanks,
>
> Mimi
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Mimi Zohar @ 2026-03-19 14:28 UTC (permalink / raw)
To: Chris Fenner
Cc: Jarkko Sakkinen, linux-integrity, Jonathan McDowell, Eric Biggers,
James Bottomley, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list, Roberto Sassu
In-Reply-To: <CAMigqh2kW_srDgnOs+1t=sk9Q9jJgaQVswO0ZRHhV-6zrOAZ6A@mail.gmail.com>
On Wed, 2026-03-18 at 10:36 -0700, Chris Fenner wrote:
> Apologies if my long message derailed this discussion. I meant to
> support Mimi's concern here and project a future vision where
> TCG_TPM2_HMAC doesn't conflict with other features.
>
> More concisely, I think that:
>
> > tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled
>
> is not a compelling argument for removing TPM as an RNG source,
> because TCG_TPM2_HMAC is known to have poor performance already
> anyway.
Agreed. Thanks, Chris! FYI, we raised concerns about IMA performance with the
TPM HMAC and encrypted feature while it was being developed. James had some
ideas, at the time, as to how to resolve the performance issue for IMA. Yet it
was upstreamed without those changes and with CONFIG_TCG_TPM2_HMAC enabled by
default on x86 systems.
Jarkko has queued this patch in the "queue" branch, without indicating whether
it will eventually be upstreamed or not.
Mimi
^ permalink raw reply
* Re: [PATCH v9 01/11] KEYS: trusted: Use get_random-fallback for TPM
From: Chris Fenner @ 2026-03-18 17:36 UTC (permalink / raw)
To: Mimi Zohar
Cc: Jarkko Sakkinen, linux-integrity, Jonathan McDowell, Eric Biggers,
James Bottomley, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED,
open list:SECURITY SUBSYSTEM, open list, Roberto Sassu
In-Reply-To: <dca994cd0ed11a262d4022c4984984460ba06a78.camel@linux.ibm.com>
Apologies if my long message derailed this discussion. I meant to
support Mimi's concern here and project a future vision where
TCG_TPM2_HMAC doesn't conflict with other features.
More concisely, I think that:
> tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled
is not a compelling argument for removing TPM as an RNG source,
because TCG_TPM2_HMAC is known to have poor performance already
anyway.
Thanks
Chris
On Thu, Mar 5, 2026 at 7:37 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> On Tue, 2026-03-03 at 23:32 +0200, Jarkko Sakkinen wrote:
> > On Fri, Feb 20, 2026 at 10:30:26AM -0800, Chris Fenner wrote:
> > > My conclusion about TCG_TPM2_HMAC after [1] and [2] was that
> > > TPM2_TCG_HMAC doesn't (or didn't at the time) actually solve the
> > > threat model it claims to (active interposer adversaries), while
> > > dramatically increasing the cost of many kernel TPM activities beyond
> > > the amount that would have been required to just solve for
> > > passive/bus-sniffer interposer adversaries. The added symmetric crypto
> > > required to secure a TPM transaction is almost not noticeable; the big
> > > performance problem is the re-bootstrapping of the session with ECDH
> > > for every command.
> > >
> > > My primary concern at that time was, essentially, that TCG_TPM2_HMAC
> > > punts on checking that the key that was used to secure the session was
> > > actually resident in a real TPM and not just an interposer adversary.
> > > I wrote up my understanding at
> > > https://www.dlp.rip/decorative-cryptography, for anyone who wants a
> > > long-form opinionated take :).
> > >
> > > Unless I'm wrong, or TCG_TPM2_HMAC has changed dramatically since
> > > August, I don't think "TPM2_TCG_HMAC makes this too costly" is a
> > > compelling reason to make a security decision. (There could be other
> > > reasons to make choices about whether to use the TPM as a source of
> > > randomness in the kernel! This just isn't one IMHO.)
> > >
> > > The version of TCG_TPM2_HMAC that I'd like to see someday would be one
> > > that fully admits that its threat model is only passive interposers,
> > > and sets up one session upon startup and ContextSaves/ContextLoads it
> > > back into the TPM as needed in order to secure parameter encryption
> > > for e.g., GetRandom() and Unseal() calls.
> >
> > Neither agreeing nor disagreeing but this patch set clearly does not
> > move forward and I spent already enough energy for this. For better
> > ideas the patches are available in queue branch.
>
> Jarkko, you totally ignored my comments below. I object to your removing the
> TPM trusted-keys RNG support.
>
> Mimi
>
> >
> > High-level takes don't move anything forward (or backward), sorry.
> >
> > >
> > > [1]: https://lore.kernel.org/linux-integrity/CAMigqh2nwuRRxaLyOJ+QaTJ+XGmkQj=rMj5K9GP1bCcXp2OsBQ@mail.gmail.com/
> > > [2]: https://lore.kernel.org/linux-integrity/20250825203223.629515-1-jarkko@kernel.org/
> > >
> > > Thanks
> > > Chris
> > >
> > > On Fri, Feb 20, 2026 at 10:04 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > >
> > > > [Cc: Chris Fenner, Jonathan McDowell, Roberto]
> > > >
> > > > On Sun, 2026-01-25 at 21:25 +0200, Jarkko Sakkinen wrote:
> > > > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> > > > > use should be pooled rather than directly used. This both reduces
> > > > > latency and improves its predictability.
> > > >
> > > > If the concern is the latency of encrypting the bus session, please remember
> > > > that:
> > > >
> > > > - Not all environments expose the TPM bus to sniffing.
> > > > - The current TPM trusted keys design is based on TPM RNG, but already allows it
> > > > to be replaced with the kernel RNG via the "trusted_rng=kernel" boot command
> > > > line option.
> > > > - The proposed patch removes that possibility for no reason.
> > > >
> > > > Mimi & Elaine
> > > >
> > > >
> >
> > BR, Jarkko
^ permalink raw reply
* Re: [PATCH v3 3/3] ima: Add support for staging measurements for deletion
From: Mimi Zohar @ 2026-03-17 21:03 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <20260311171956.2317781-3-roberto.sassu@huaweicloud.com>
Hi Roberto,
On Wed, 2026-03-11 at 18:19 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduce the ability of staging the IMA measurement list for deletion.
> Staging means moving the current content of the measurement list to a
> separate location, and allowing users to read and delete it. This causes
> the measurement list to be atomically truncated before new measurements can
> be added.
I really like this design of atomically moving and subsequently deleting the
measurement list. However this is a solution, not the motivation for the patch.
Please include the motivation for the patch, before describing the solution.
> Staging can be done only once at a time. In the event of kexec(),
> staging is reverted and staged entries will be carried over to the new
> kernel.
>
> Staged measurements can be deleted entirely, or partially, with the
> non-deleted ones added back to the IMA measurements list.
This patch description is really long, which is an indication that the patch
needs to be split up. Adding support for partially deleting the measurement
list records, by prepending the remaining measurement records, should be a
separate patch.
> This allows the
> remote attestation agents to easily separate the measurements that where
> verified (staged and deleted) from those that weren't due to the race
> between taking a TPM quote and reading the measurements list.
>
> User space is responsible to concatenate the staged IMA measurements list
> portions (excluding the measurements added back to the IMA measurements
> list) following the temporal order in which the operations were done,
> together with the current measurement list. Then, it can send the collected
> data to the remote verifiers.
This belongs in a Documentation patch.
>
> The benefit of staging and deleting is the ability to free precious kernel
> memory,
This is the motivation for the patch.
> in exchange of delegating user space to reconstruct the full
> measurement list from the chunks. No trust needs to be given to user space,
> since the integrity of the measurement list is protected by the TPM.
Agreed the measurement list, itself, is protected by the TPM. However, relying
on userspace to reassemble the chunks is another concern. Support for staging
and deleting the measurement list should be configurable. Defining a Kconfig
should be part of this initial patch.
> By default, staging the measurements list does not alter the hash table.
> When staging and deleting are done, IMA is still able to detect collisions
> on the staged and later deleted measurement entries, by keeping the entry
> digests (only template data are freed).
>
> However, since during the measurements list serialization only the SHA1
> digest is passed, and since there are no template data to recalculate the
> other digests from, the hash table is currently not populated with digests
> from staged/deleted entries after kexec().
>
> Introduce the new kernel option ima_flush_htable to decide whether or not
> the digests of staged measurement entries are flushed from the hash table,
> when they are deleted. Flushing the hash table is supported only when
> deleting all the staged measurements, since in that case the old hash table
> can be quickly swapped with a blank one (otherwise entries would have to be
> removed one by one for partial deletion).
Allowing the hash table to be deleted would be an example of another patch.
>
> Then, introduce ascii_runtime_measurements_<algo>_staged and
> binary_runtime_measurements_<algo>_staged interfaces to stage and delete
> the measurements. Use 'echo A > <IMA interface>' and
> 'echo D > <IMA interface>' to respectively stage and delete the entire
> measurements list. Use 'echo N > <IMA interface>', with N between 1 and
> ULONG_MAX - 1, to delete the selected staged portion of the measurements
> list.
>
> The ima_measure_users counter (protected by the ima_measure_mutex mutex)
> has been introduced to protect access to the measurements list and the
> staged part. The open method of all the measurement interfaces has been
> extended to allow only one writer at a time or, in alternative, multiple
> readers. The write permission is used to stage and delete the measurements,
> the read permission to read them. Write requires also the CAP_SYS_ADMIN
> capability.
Yes, this is part of the initial patch that adds support for staging the
measurement list.
>
> Finally, introduce the binary_lists enum and make binary_runtime_size
> and ima_num_entries as arrays, to keep track of their values for the
> current IMA measurements list (BINARY), current list plus staged
> measurements (BINARY_STAGED) and the cumulative list since IMA
> initialization (BINARY_FULL).
>
> Use BINARY in ima_show_measurements_count(), BINARY_STAGED in
> ima_add_kexec_buffer() and BINARY_FULL in ima_measure_kexec_event().
>
> It should be noted that the BINARY_FULL counter is not passed through
> kexec. Thus, the number of entries included in the kexec critical data
> records refers to the entries since the previous kexec records.
>
> Note: This code derives from the Alt-IMA Huawei project, whose license is
> GPL-2.0 OR MIT.
>
> Link: https://github.com/linux-integrity/linux/issues/1
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
The design looks good. As I mentioned above, this patch description is quite
long, which is an indication that the patch needs to be split up. One method of
breaking it up would be:
- (Basic) support for staging measurements for deletion (based on a Kconfig)
- Support for removing the hash table
- Support for deleting N measurement records (and pre-pending the remaining
measurement records)
- Adding documentation
thanks,
Mimi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox