* [PATCH 2/4] tpm: Move TPM1 specific definitions to the command header
From: Alec Brown @ 2026-03-17 16:03 UTC (permalink / raw)
To: linux-kernel, linux-integrity, jarkko
Cc: peterhuewe, jarkko.sakkinen, jgg, ross.philipson, dpsmith,
daniel.kiper, kanth.ghatraju, trenchboot-devel, ardb,
alec.r.brown
In-Reply-To: <20260317160613.2899129-1-alec.r.brown@oracle.com>
From: Ross Philipson <ross.philipson@oracle.com>
From: Ross Philipson <ross.philipson@oracle.com>
Gather all the TPM1 definitions and structures in the internal header
file drivers/char/tpm/tpm.h into the command header. In addition, bring
in the single RNG structure from tpm-interface.c.
The definitions moved to these files correspond to the TCG specification
for TPM 1 family:
TPM 1.2 Main Specification
- https://trustedcomputinggroup.org/resource/tpm-main-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 | 102 --------------------------------
drivers/char/tpm/tpm1-cmd.c | 5 --
include/linux/tpm_command.h | 115 ++++++++++++++++++++++++++++++++++++
3 files changed, 115 insertions(+), 107 deletions(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 02c07fef41ba..1a9a46a921fe 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -51,105 +51,9 @@ enum tpm_addr {
TPM_ADDR = 0x4E,
};
-#define TPM_WARN_RETRY 0x800
-#define TPM_WARN_DOING_SELFTEST 0x802
-#define TPM_ERR_DEACTIVATED 0x6
-#define TPM_ERR_DISABLED 0x7
-#define TPM_ERR_FAILEDSELFTEST 0x1C
-#define TPM_ERR_INVALID_POSTINIT 38
-
-#define TPM_TAG_RQU_COMMAND 193
-
/* TPM2 specific constants. */
#define TPM2_SPACE_BUFFER_SIZE 16384 /* 16 kB */
-struct stclear_flags_t {
- __be16 tag;
- u8 deactivated;
- u8 disableForceClear;
- u8 physicalPresence;
- u8 physicalPresenceLock;
- u8 bGlobalLock;
-} __packed;
-
-struct tpm1_version {
- u8 major;
- u8 minor;
- u8 rev_major;
- u8 rev_minor;
-} __packed;
-
-struct tpm1_version2 {
- __be16 tag;
- struct tpm1_version version;
-} __packed;
-
-struct timeout_t {
- __be32 a;
- __be32 b;
- __be32 c;
- __be32 d;
-} __packed;
-
-struct duration_t {
- __be32 tpm_short;
- __be32 tpm_medium;
- __be32 tpm_long;
-} __packed;
-
-struct permanent_flags_t {
- __be16 tag;
- u8 disable;
- u8 ownership;
- u8 deactivated;
- u8 readPubek;
- u8 disableOwnerClear;
- u8 allowMaintenance;
- u8 physicalPresenceLifetimeLock;
- u8 physicalPresenceHWEnable;
- u8 physicalPresenceCMDEnable;
- u8 CEKPUsed;
- u8 TPMpost;
- u8 TPMpostLock;
- u8 FIPS;
- u8 operator;
- u8 enableRevokeEK;
- u8 nvLocked;
- u8 readSRKPub;
- u8 tpmEstablished;
- u8 maintenanceDone;
- u8 disableFullDALogicInfo;
-} __packed;
-
-typedef union {
- struct permanent_flags_t perm_flags;
- struct stclear_flags_t stclear_flags;
- __u8 owned;
- __be32 num_pcrs;
- struct tpm1_version version1;
- struct tpm1_version2 version2;
- __be32 manufacturer_id;
- struct timeout_t timeout;
- struct duration_t duration;
-} cap_t;
-
-enum tpm_capabilities {
- TPM_CAP_FLAG = 4,
- TPM_CAP_PROP = 5,
- TPM_CAP_VERSION_1_1 = 0x06,
- TPM_CAP_VERSION_1_2 = 0x1A,
-};
-
-enum tpm_sub_capabilities {
- TPM_CAP_PROP_PCR = 0x101,
- TPM_CAP_PROP_MANUFACTURER = 0x103,
- TPM_CAP_FLAG_PERM = 0x108,
- TPM_CAP_FLAG_VOL = 0x109,
- TPM_CAP_PROP_OWNER = 0x111,
- TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
- TPM_CAP_PROP_TIS_DURATION = 0x120,
-};
-
enum tpm2_pt_props {
TPM2_PT_NONE = 0x00000000,
TPM2_PT_GROUP = 0x00000100,
@@ -224,12 +128,6 @@ enum tpm2_pt_props {
TPM2_PT_AUDIT_COUNTER_1 = TPM2_PT_VAR + 20,
};
-/* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
- * bytes, but 128 is still a relatively large number of random bytes and
- * anything much bigger causes users of struct tpm_cmd_t to start getting
- * compiler warnings about stack frame size. */
-#define TPM_MAX_RNG_DATA 128
-
extern const struct class tpm_class;
extern const struct class tpmrm_class;
extern dev_t tpm_devt;
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 664ca1fff2e8..96f189b5fd6f 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -504,11 +504,6 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
}
EXPORT_SYMBOL_GPL(tpm1_getcap);
-struct tpm1_get_random_out {
- __be32 rng_data_len;
- u8 rng_data[TPM_MAX_RNG_DATA];
-} __packed;
-
/**
* tpm1_get_random() - get random bytes from the TPM's RNG
* @chip: a &struct tpm_chip instance
diff --git a/include/linux/tpm_command.h b/include/linux/tpm_command.h
index 9a8991b8801d..20b634591fb1 100644
--- a/include/linux/tpm_command.h
+++ b/include/linux/tpm_command.h
@@ -38,6 +38,121 @@ enum tpm_command_ordinals {
TPM_ORD_UNSEAL = 24,
};
+enum tpm_capabilities {
+ TPM_CAP_FLAG = 4,
+ TPM_CAP_PROP = 5,
+ TPM_CAP_VERSION_1_1 = 0x06,
+ TPM_CAP_VERSION_1_2 = 0x1A,
+};
+
+enum tpm_sub_capabilities {
+ TPM_CAP_PROP_PCR = 0x101,
+ TPM_CAP_PROP_MANUFACTURER = 0x103,
+ TPM_CAP_FLAG_PERM = 0x108,
+ TPM_CAP_FLAG_VOL = 0x109,
+ TPM_CAP_PROP_OWNER = 0x111,
+ TPM_CAP_PROP_TIS_TIMEOUT = 0x115,
+ TPM_CAP_PROP_TIS_DURATION = 0x120,
+};
+
+/* Return Codes */
+enum tpm_return_codes {
+ TPM_BASE_MASK = 0,
+ TPM_NON_FATAL_MASK = 0x00000800,
+ TPM_SUCCESS = TPM_BASE_MASK + 0,
+ TPM_ERR_DEACTIVATED = TPM_BASE_MASK + 6,
+ TPM_ERR_DISABLED = TPM_BASE_MASK + 7,
+ TPM_ERR_FAIL = TPM_BASE_MASK + 9,
+ TPM_ERR_FAILEDSELFTEST = TPM_BASE_MASK + 28,
+ TPM_ERR_INVALID_POSTINIT = TPM_BASE_MASK + 38,
+ TPM_ERR_INVALID_FAMILY = TPM_BASE_MASK + 55,
+ TPM_WARN_RETRY = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 0,
+ TPM_WARN_DOING_SELFTEST = TPM_BASE_MASK + TPM_NON_FATAL_MASK + 2,
+};
+
+struct stclear_flags_t {
+ __be16 tag;
+ u8 deactivated;
+ u8 disableForceClear;
+ u8 physicalPresence;
+ u8 physicalPresenceLock;
+ u8 bGlobalLock;
+} __packed;
+
+struct tpm1_version {
+ u8 major;
+ u8 minor;
+ u8 rev_major;
+ u8 rev_minor;
+} __packed;
+
+struct tpm1_version2 {
+ __be16 tag;
+ struct tpm1_version version;
+} __packed;
+
+struct timeout_t {
+ __be32 a;
+ __be32 b;
+ __be32 c;
+ __be32 d;
+} __packed;
+
+struct duration_t {
+ __be32 tpm_short;
+ __be32 tpm_medium;
+ __be32 tpm_long;
+} __packed;
+
+struct permanent_flags_t {
+ __be16 tag;
+ u8 disable;
+ u8 ownership;
+ u8 deactivated;
+ u8 readPubek;
+ u8 disableOwnerClear;
+ u8 allowMaintenance;
+ u8 physicalPresenceLifetimeLock;
+ u8 physicalPresenceHWEnable;
+ u8 physicalPresenceCMDEnable;
+ u8 CEKPUsed;
+ u8 TPMpost;
+ u8 TPMpostLock;
+ u8 FIPS;
+ u8 operator;
+ u8 enableRevokeEK;
+ u8 nvLocked;
+ u8 readSRKPub;
+ u8 tpmEstablished;
+ u8 maintenanceDone;
+ u8 disableFullDALogicInfo;
+} __packed;
+
+typedef union {
+ struct permanent_flags_t perm_flags;
+ struct stclear_flags_t stclear_flags;
+ __u8 owned;
+ __be32 num_pcrs;
+ struct tpm1_version version1;
+ struct tpm1_version2 version2;
+ __be32 manufacturer_id;
+ struct timeout_t timeout;
+ struct duration_t duration;
+} cap_t;
+
+/*
+ * 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
+ * bytes, but 128 is still a relatively large number of random bytes and
+ * anything much bigger causes users of struct tpm_cmd_t to start getting
+ * compiler warnings about stack frame size.
+ */
+#define TPM_MAX_RNG_DATA 128
+
+struct tpm1_get_random_out {
+ __be32 rng_data_len;
+ u8 rng_data[TPM_MAX_RNG_DATA];
+} __packed;
+
/* Other constants */
#define SRKHANDLE 0x40000000
#define TPM_NONCE_SIZE 20
--
2.47.3
^ permalink raw reply related
* [PATCH 3/4] tpm: Move TPM2 specific definitions to the command header
From: Alec Brown @ 2026-03-17 16:03 UTC (permalink / raw)
To: linux-kernel, linux-integrity, jarkko
Cc: peterhuewe, jarkko.sakkinen, jgg, ross.philipson, dpsmith,
daniel.kiper, kanth.ghatraju, trenchboot-devel, ardb,
alec.r.brown
In-Reply-To: <20260317160613.2899129-1-alec.r.brown@oracle.com>
From: Ross Philipson <ross.philipson@oracle.com>
From: Ross Philipson <ross.philipson@oracle.com>
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
^ permalink raw reply related
* Re: [PATCH v3 1/3] ima: Remove ima_h_table structure
From: Mimi Zohar @ 2026-03-17 19:15 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-1-roberto.sassu@huaweicloud.com>
On Wed, 2026-03-11 at 18:19 +0100, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> With the upcoming change of dynamically allocating and replacing the hash
> table, we would need to keep the counters for number of measurements
> entries and violations.
>
> Since anyway, those counters don't belong there, remove the ima_h_table
> structure instead and move the counters and the hash table as a separate
> variables.
There's no cover letter or motivation in this patch description for needing to
"dynamically allocating or replacing the existing hash table."
Saying that the htable, number of records in the measurement list, and violation
counter don't belong grouped together is insufficient. There must have been a
valid reason for why they were grouped together originally (e.g. never removed
or reset).
Please provide a motivation for removing the ima_h_table struct and its usage
and defining them independently of each other.
thanks,
Mimi
^ 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
* 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 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 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 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-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: 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: 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: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: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 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 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
* [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] 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] 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 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
* 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 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 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 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: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] 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
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