Address !chip->auth

On Wed, 2024-07-03 at 21:24 +0300, Jarkko Sakkinen wrote:
[...]

include/linux/tpm.h struct tpm_chip { · line 216

Quoted 12 lines

include/linux/tpm.h +1 -1

index 21a67dc9efe8..2844fea4a12a 100644
@@ -211,8 +211,8 @@ struct tpm_chip {
         u8 null_key_name[TPM2_NAME_SIZE];
         u8 null_ec_key_x[EC_PT_SZ];
         u8 null_ec_key_y[EC_PT_SZ];
-       struct tpm2_auth *auth;
  #endif
+       struct tpm2_auth *auth;
  };

Since auth should only be present if CONFIG_TCG_TPM2_HMAC this is clearly an undesirable thing to do. I think you did it because in a later patch you want to collapse the hmac sessions to use a single routine, but you can make that check with the preprocessor __and function defined in kconfig.h:

if (__and(IS_ENABLED(CONFIG_TCG_TPM2_HMAC), chip->auth))

Which will become 0 if the config is not enabled and chip->auth if it is, thus eliminating the code in the former case while not causing the compiler to complain about chip->auth not being defined even if it's under the config parameter.

James

if (__and(IS_ENABLED(CONFIG_TCG_TPM2_HMAC), chip->auth))

Quoted 2 lines · James Bottomley

if (__and(IS_ENABLED(CONFIG_TCG_TPM2_HMAC), chip->auth))

Augh. Please don't do this.

That "__and()" thing may work, but it's entirely accidental that it does.

It's designed for config options _only_, and the fact that it then happens to work for "first argument is config option, second argument is C conditional".

The comment says that it's implementing "&&" using preprocessor expansion only, but it's a *really* limited form of it. The arguments are *not* arbitrary.

So no. Don't do this.

Just create a helper inline like

    static inline struct tpm2_auth *chip_auth(struct tpm_chip *chip) {
    #ifdef CONFIG_TCG_TPM2_HMAC
        return chip->auth;
    #else
        return NULL;
    #endif
    }

and if we really want to have some kind of automatic way of doing this, we will *NOT* be using __and(), we'd do something like

        /* Return zero or 'value' depending on whether OPTION is enabled or not */
        #define IF_ENABLED(option, value) __and(IS_ENABLED(option), value)

that actually would be documented and meaningful.

Not this internal random __and() implementation that is purely a kconfig.h helper macro and SHOULD NOT be used anywhere else.

Quoted 41 lines · Linus Torvalds

Quoted 2 lines · James Bottomley

if (__and(IS_ENABLED(CONFIG_TCG_TPM2_HMAC), chip->auth))

Augh. Please don't do this.

That "__and()" thing may work, but it's entirely accidental that it does.

It's designed for config options _only_, and the fact that it then happens to work for "first argument is config option, second argument is C conditional".

The comment says that it's implementing "&&" using preprocessor expansion only, but it's a *really* limited form of it. The arguments are *not* arbitrary.

So no. Don't do this.

Just create a helper inline like

    static inline struct tpm2_auth *chip_auth(struct tpm_chip *chip) {
    #ifdef CONFIG_TCG_TPM2_HMAC
        return chip->auth;
    #else
        return NULL;
    #endif
    }

and if we really want to have some kind of automatic way of doing this, we will *NOT* be using __and(), we'd do something like

        /* Return zero or 'value' depending on whether OPTION is enabled or not */
        #define IF_ENABLED(option, value) __and(IS_ENABLED(option), value)

that actually would be documented and meaningful.

Quoted 2 lines

Not this internal random __and() implementation that is purely a kconfig.h helper macro and SHOULD NOT be used anywhere else.

I actually like the latter version, but instinct tells me that if this is the first time the kernel has ever needed something like this then perhaps we should go with the former because that's how everyone must have handled it in the past.

James

Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can

cause a null derefence in tpm_buf_hmac_session*(). Thus, address !chip->auth in tpm_buf_hmac_session*() and remove the fallback implementation for !TCG_TPM2_HMAC.

Cc [email protected] # v6.9+

Reported-by Stefan Berger <[email protected]>

Closes https://lore.kernel.org/linux-integrity/[email protected]/ open here

Fixes 1085b8276bb4 ("tpm: Add the rest of the session HMAC API")

Signed-off-by Jarkko Sakkinen <[email protected]>

---
v2:
- Use auth in place of chip->auth.

---
  drivers/char/tpm/tpm2-sessions.c | 181 ++++++++++++++++++-------------
  include/linux/tpm.h              |  67 ++++--------
  2 files changed, 124 insertions(+), 124 deletions(-)

drivers/char/tpm/tpm2-sessions.c +105 -76

index 06d0f10a2301..304247090b56 100644
@@ -268,6 +268,105 @@ void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
  }
  EXPORT_SYMBOL_GPL(tpm_buf_append_name);
 
+/**
+ * tpm_buf_append_hmac_session() - Append a TPM session element
+ * @chip: the TPM chip structure
+ * @buf: The buffer to be appended
+ * @attributes: The session attributes
+ * @passphrase: The session authority (NULL if none)
+ * @passphrase_len: The length of the session authority (0 if none)
+ *
+ * This fills in a session structure in the TPM command buffer, except
+ * for the HMAC which cannot be computed until the command buffer is
+ * complete.  The type of session is controlled by the @attributes,
+ * the main ones of which are TPM2_SA_CONTINUE_SESSION which means the
+ * session won't terminate after tpm_buf_check_hmac_response(),
+ * TPM2_SA_DECRYPT which means this buffers first parameter should be
+ * encrypted with a session key and TPM2_SA_ENCRYPT, which means the
+ * response buffer's first parameter needs to be decrypted (confusing,
+ * but the defines are written from the point of view of the TPM).
+ *
+ * Any session appended by this command must be finalized by calling
+ * tpm_buf_fill_hmac_session() otherwise the HMAC will be incorrect
+ * and the TPM will reject the command.
+ *
+ * As with most tpm_buf operations, success is assumed because failure
+ * will be caused by an incorrect programming model and indicated by a
+ * kernel message.
+ */
+void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf,
+				 u8 attributes, u8 *passphrase,
+				 int passphrase_len)
+{
+	struct tpm2_auth *auth = chip->auth;
+	u8 nonce[SHA256_DIGEST_SIZE];
+	u32 len;
+
+	if (!auth) {
+		/* offset tells us where the sessions area begins */
+		int offset = buf->handles * 4 + TPM_HEADER_SIZE;
+		u32 len = 9 + passphrase_len;
+
+		if (tpm_buf_length(buf) != offset) {
+			/* not the first session so update the existing length */
+			len += get_unaligned_be32(&buf->data[offset]);
+			put_unaligned_be32(len, &buf->data[offset]);
+		} else {
+			tpm_buf_append_u32(buf, len);
+		}
+		/* auth handle */
+		tpm_buf_append_u32(buf, TPM2_RS_PW);
+		/* nonce */
+		tpm_buf_append_u16(buf, 0);
+		/* attributes */
+		tpm_buf_append_u8(buf, 0);
+		/* passphrase */
+		tpm_buf_append_u16(buf, passphrase_len);
+		tpm_buf_append(buf, passphrase, passphrase_len);
+		return;
+	}
+
+	/*
+	 * The Architecture Guide requires us to strip trailing zeros
+	 * before computing the HMAC
+	 */
+	while (passphrase && passphrase_len > 0 && passphrase[passphrase_len - 1] == '\0')
+		passphrase_len--;
+
+	auth->attrs = attributes;
+	auth->passphrase_len = passphrase_len;
+	if (passphrase_len)
+		memcpy(auth->passphrase, passphrase, passphrase_len);
+
+	if (auth->session != tpm_buf_length(buf)) {
+		/* we're not the first session */
+		len = get_unaligned_be32(&buf->data[auth->session]);
+		if (4 + len + auth->session != tpm_buf_length(buf)) {
+			WARN(1, "session length mismatch, cannot append");
+			return;
+		}
+
+		/* add our new session */
+		len += 9 + 2 * SHA256_DIGEST_SIZE;
+		put_unaligned_be32(len, &buf->data[auth->session]);
+	} else {
+		tpm_buf_append_u32(buf, 9 + 2 * SHA256_DIGEST_SIZE);
+	}
+
+	/* random number for our nonce */
+	get_random_bytes(nonce, sizeof(nonce));
+	memcpy(auth->our_nonce, nonce, sizeof(nonce));
+	tpm_buf_append_u32(buf, auth->handle);
+	/* our new nonce */
+	tpm_buf_append_u16(buf, SHA256_DIGEST_SIZE);
+	tpm_buf_append(buf, nonce, SHA256_DIGEST_SIZE);
+	tpm_buf_append_u8(buf, auth->attrs);
+	/* and put a placeholder for the hmac */
+	tpm_buf_append_u16(buf, SHA256_DIGEST_SIZE);
+	tpm_buf_append(buf, nonce, SHA256_DIGEST_SIZE);
+}
+EXPORT_SYMBOL_GPL(tpm_buf_append_hmac_session);
+
  #ifdef CONFIG_TCG_TPM2_HMAC
  /*
   * It turns out the crypto hmac(sha256) is hard for us to consume

@@ -449,82 +548,6 @@ static void tpm_buf_append_salt(struct tpm_buf *buf, struct tpm_chip *chip)
  	crypto_free_kpp(kpp);
  }
 
-/**
- * tpm_buf_append_hmac_session() - Append a TPM session element
- * @chip: the TPM chip structure
- * @buf: The buffer to be appended
- * @attributes: The session attributes
- * @passphrase: The session authority (NULL if none)
- * @passphrase_len: The length of the session authority (0 if none)
- *
- * This fills in a session structure in the TPM command buffer, except
- * for the HMAC which cannot be computed until the command buffer is
- * complete.  The type of session is controlled by the @attributes,
- * the main ones of which are TPM2_SA_CONTINUE_SESSION which means the
- * session won't terminate after tpm_buf_check_hmac_response(),
- * TPM2_SA_DECRYPT which means this buffers first parameter should be
- * encrypted with a session key and TPM2_SA_ENCRYPT, which means the
- * response buffer's first parameter needs to be decrypted (confusing,
- * but the defines are written from the point of view of the TPM).
- *
- * Any session appended by this command must be finalized by calling
- * tpm_buf_fill_hmac_session() otherwise the HMAC will be incorrect
- * and the TPM will reject the command.
- *
- * As with most tpm_buf operations, success is assumed because failure
- * will be caused by an incorrect programming model and indicated by a
- * kernel message.
- */
-void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf,
-				 u8 attributes, u8 *passphrase,
-				 int passphrase_len)
-{
-	u8 nonce[SHA256_DIGEST_SIZE];
-	u32 len;
-	struct tpm2_auth *auth = chip->auth;
-
-	/*
-	 * The Architecture Guide requires us to strip trailing zeros
-	 * before computing the HMAC
-	 */
-	while (passphrase && passphrase_len > 0
-	       && passphrase[passphrase_len - 1] == '\0')
-		passphrase_len--;
-
-	auth->attrs = attributes;
-	auth->passphrase_len = passphrase_len;
-	if (passphrase_len)
-		memcpy(auth->passphrase, passphrase, passphrase_len);
-
-	if (auth->session != tpm_buf_length(buf)) {
-		/* we're not the first session */
-		len = get_unaligned_be32(&buf->data[auth->session]);
-		if (4 + len + auth->session != tpm_buf_length(buf)) {
-			WARN(1, "session length mismatch, cannot append");
-			return;
-		}
-
-		/* add our new session */
-		len += 9 + 2 * SHA256_DIGEST_SIZE;
-		put_unaligned_be32(len, &buf->data[auth->session]);
-	} else {
-		tpm_buf_append_u32(buf, 9 + 2 * SHA256_DIGEST_SIZE);
-	}
-
-	/* random number for our nonce */
-	get_random_bytes(nonce, sizeof(nonce));
-	memcpy(auth->our_nonce, nonce, sizeof(nonce));
-	tpm_buf_append_u32(buf, auth->handle);
-	/* our new nonce */
-	tpm_buf_append_u16(buf, SHA256_DIGEST_SIZE);
-	tpm_buf_append(buf, nonce, SHA256_DIGEST_SIZE);
-	tpm_buf_append_u8(buf, auth->attrs);
-	/* and put a placeholder for the hmac */
-	tpm_buf_append_u16(buf, SHA256_DIGEST_SIZE);
-	tpm_buf_append(buf, nonce, SHA256_DIGEST_SIZE);
-}
-EXPORT_SYMBOL(tpm_buf_append_hmac_session);
-
  /**
   * tpm_buf_fill_hmac_session() - finalize the session HMAC
   * @chip: the TPM chip structure

@@ -555,6 +578,9 @@ void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf)
  	u8 cphash[SHA256_DIGEST_SIZE];
  	struct sha256_state sctx;
 
+	if (!auth)
+		return;
+
  	/* save the command code in BE format */
  	auth->ordinal = head->ordinal;
 

@@ -713,6 +739,9 @@ int tpm_buf_check_hmac_response(struct tpm_chip *chip, struct tpm_buf *buf,
  	u32 cc = be32_to_cpu(auth->ordinal);
  	int parm_len, len, i, handles;
 
+	if (!auth)
+		return rc;
+
  	if (auth->session >= TPM_HEADER_SIZE) {
  		WARN(1, "tpm session not filled correctly\n");
  		goto out;

include/linux/tpm.h +19 -48

index 2844fea4a12a..912fd0d2646d 100644
@@ -493,22 +493,35 @@ static inline void tpm_buf_append_empty_auth(struct tpm_buf *buf, u32 handle)
 
  void tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
  			 u32 handle, u8 *name);
-
-#ifdef CONFIG_TCG_TPM2_HMAC
-
-int tpm2_start_auth_session(struct tpm_chip *chip);
  void tpm_buf_append_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf,
  				 u8 attributes, u8 *passphrase,
  				 int passphraselen);
+
  static inline void tpm_buf_append_hmac_session_opt(struct tpm_chip *chip,
  						   struct tpm_buf *buf,
  						   u8 attributes,
  						   u8 *passphrase,
  						   int passphraselen)
  {
-	tpm_buf_append_hmac_session(chip, buf, attributes, passphrase,
-				    passphraselen);
+	struct tpm_header *head = (struct tpm_header *)buf->data;
+	int offset = buf->handles * 4 + TPM_HEADER_SIZE;
+
+	if (chip->auth) {
+		tpm_buf_append_hmac_session(chip, buf, attributes, passphrase,
+					    passphraselen);
+	} else  {
+		/*
+		 * If the only sessions are optional, the command tag must change to
+		 * TPM2_ST_NO_SESSIONS.
+		 */
+		if (tpm_buf_length(buf) == offset)
+			head->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
+	}
  }
+
+#ifdef CONFIG_TCG_TPM2_HMAC
+
+int tpm2_start_auth_session(struct tpm_chip *chip);
  void tpm_buf_fill_hmac_session(struct tpm_chip *chip, struct tpm_buf *buf);
  int tpm_buf_check_hmac_response(struct tpm_chip *chip, struct tpm_buf *buf,
  				int rc);

@@ -523,48 +536,6 @@ static inline int tpm2_start_auth_session(struct tpm_chip *chip)
  static inline void tpm2_end_auth_session(struct tpm_chip *chip)
  {
  }
-static inline void tpm_buf_append_hmac_session(struct tpm_chip *chip,
-					       struct tpm_buf *buf,
-					       u8 attributes, u8 *passphrase,
-					       int passphraselen)
-{
-	/* offset tells us where the sessions area begins */
-	int offset = buf->handles * 4 + TPM_HEADER_SIZE;
-	u32 len = 9 + passphraselen;
-
-	if (tpm_buf_length(buf) != offset) {
-		/* not the first session so update the existing length */
-		len += get_unaligned_be32(&buf->data[offset]);
-		put_unaligned_be32(len, &buf->data[offset]);
-	} else {
-		tpm_buf_append_u32(buf, len);
-	}
-	/* auth handle */
-	tpm_buf_append_u32(buf, TPM2_RS_PW);
-	/* nonce */
-	tpm_buf_append_u16(buf, 0);
-	/* attributes */
-	tpm_buf_append_u8(buf, 0);
-	/* passphrase */
-	tpm_buf_append_u16(buf, passphraselen);
-	tpm_buf_append(buf, passphrase, passphraselen);
-}
-static inline void tpm_buf_append_hmac_session_opt(struct tpm_chip *chip,
-						   struct tpm_buf *buf,
-						   u8 attributes,
-						   u8 *passphrase,
-						   int passphraselen)
-{
-	int offset = buf->handles * 4 + TPM_HEADER_SIZE;
-	struct tpm_header *head = (struct tpm_header *) buf->data;
-
-	/*
-	 * if the only sessions are optional, the command tag
-	 * must change to TPM2_ST_NO_SESSIONS
-	 */
-	if (tpm_buf_length(buf) == offset)
-		head->tag = cpu_to_be16(TPM2_ST_NO_SESSIONS);
-}
  static inline void tpm_buf_fill_hmac_session(struct tpm_chip *chip,
  					     struct tpm_buf *buf)
  {

Quoted 1 line · Jarkko Sakkinen

Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can

Doesn't tpm_chip_register() need to be called by all drivers? This function then calls tpm_chip_bootstrap().

Quoted 4 lines

cause a null derefence in tpm_buf_hmac_session*(). Thus, address !chip->auth in tpm_buf_hmac_session*() and remove the fallback implementation for !TCG_TPM2_HMAC.

Quoted 5 lines

Cc [email protected] # v6.9+

Reported-by Stefan Berger <[email protected]>

Closes https://lore.kernel.org/linux-integrity/[email protected]/ open here

Fixes 1085b8276bb4 ("tpm: Add the rest of the session HMAC API")

Signed-off-by Jarkko Sakkinen <[email protected]>

I applied this series now but it doesn't solve the reported problem. The

error message is gone but the feature can still be enabled (CONFIG_TCG_TPM2_HMAC=y) but is unlikely actually doing what it is promising to do with this config option. So you either still have to apply my patch, James's patch, or your intended "depends on !TCG_IBMVTPM" patch.

Quoted 12 lines · Stefan Berger

Quoted 1 line · Jarkko Sakkinen

Unless tpm_chip_bootstrap() was called by the driver, !chip->auth can

Doesn't tpm_chip_register() need to be called by all drivers? This function then calls tpm_chip_bootstrap().

Quoted 4 lines

cause a null derefence in tpm_buf_hmac_session*(). Thus, address !chip->auth in tpm_buf_hmac_session*() and remove the fallback implementation for !TCG_TPM2_HMAC.

Quoted 7 lines

Quoted 5 lines

Cc [email protected] # v6.9+

Reported-by Stefan Berger <[email protected]>

Closes https://lore.kernel.org/linux-integrity/[email protected]/ open here

Fixes 1085b8276bb4 ("tpm: Add the rest of the session HMAC API")

Signed-off-by Jarkko Sakkinen <[email protected]>

I applied this series now but it doesn't solve the reported problem. The

It fixes the issues of which symptoms was shown by your transcript:

[    2.987131] tpm tpm0: tpm2_load_context: failed with a TPM error 0x01C4
[    2.987140] ima: Error Communicating to TPM chip, result: -14

Your original thread identified zero problems, so thus your claim here is plain untrue.

Before the null derefence is fixed all other patches related are blocked, including ibm_tpmvtpm patches, because it would be insane to accept them when there is known memory corruption bug, which this patch set fixes.

What is so difficult to understand in this?

Quoted 5 lines

error message is gone but the feature can still be enabled (CONFIG_TCG_TPM2_HMAC=y) but is unlikely actually doing what it is promising to do with this config option. So you either still have to apply my patch, James's patch, or your intended "depends on !TCG_IBMVTPM" patch.

Well this somewhat misleading imho...

None of the previous patches, including your, do nothing to fix the null derefence bug and that is the *only* bug we care about ATM. With these fixes drivers that do not call tpm_chip_bootstrap() will be fully working still but without encryption.

There's five drivers which would require update for that:

drivers/char/tpm/tpm_ftpm_tee.c: pvt_data->chip->flags |= TPM_CHIP_FLAG_TPM2;
drivers/char/tpm/tpm_i2c_nuvoton.c: chip->flags |= TPM_CHIP_FLAG_TPM2;

drivers/char/tpm/tpm_ibmvtpm.c:         chip->flags |= TPM_CHIP_FLAG_TPM2;
drivers/char/tpm/tpm_tis_i2c_cr50.c:    chip->flags |= TPM_CHIP_FLAG_TPM2;

drivers/char/tpm/tpm_vtpm_proxy.c: proxy_dev->chip->flags |= TPM_CHIP_FLAG_TPM2;

BR, Jarkko

The original thread here

https://lore.kernel.org/linux-integrity/[email protected]/T/#t

identified the fact that tpm2_session_init() was missing for the ibmvtpm driver. It is a non-zero problem for the respective platforms where this driver is being used. The patched fixed the reported issue.

Now that you fixed it in v4 are you going to accept my original patch with the Fixes tag since we will (likely) have an enabled feature in 6.10 that is not actually working when the ibmvtpm driver is being used?

I do no think that this is true and its only tpm_ibmvtpm.c that need the call to tpm2_session_init. All drivers that use TPM_OPS_AUTO_STARTUP will run tpm_chip_register -> tpm_chip_bootstrap -> tpm_auto_startup -> tpm2_auto_startup -> tpm2_sessions_init

Quoted 7 lines · Stefan Berger

The original thread here

https://lore.kernel.org/linux-integrity/[email protected]/T/#t

identified the fact that tpm2_session_init() was missing for the ibmvtpm driver. It is a non-zero problem for the respective platforms where this driver is being used. The patched fixed the reported issue.

All bugs needs to be fixed always before features are added. You are free now to submit your change as a feature patch, which will be reviewed and applied later on.

Quoted 3 lines

Now that you fixed it in v4 are you going to accept my original patch with the Fixes tag since we will (likely) have an enabled feature in 6.10 that is not actually working when the ibmvtpm driver is being used?

There's no bug in tpm_ibmvtpm driver as it functions as well as in 6.9.

I can review it earliest in the week 31, as feature patch. This was my holiday week, and I came back only to fix the bug in the authentication session patch set.

Quoted 4 lines

I do no think that this is true and its only tpm_ibmvtpm.c that need the call to tpm2_session_init. All drivers that use TPM_OPS_AUTO_STARTUP will run tpm_chip_register -> tpm_chip_bootstrap -> tpm_auto_startup -> tpm2_auto_startup -> tpm2_sessions_init

Right my bad. I overlooked the call sites and you're correct in that for anything with that flag on, it will be called.

It still changes nothing, as the commit you were pointing out in the fixes tag does not implement initialization code, and we would not have that flag in the first place, if it was mandatory [1].

[1] It could be that it is mandatory perhaps, but that is a different story. Then we would render the whole flag out. I think this was anyway good insight, even if by unintentionally, and we can reconsider removing it some day.

[    1.449673] tpm_ibmvtpm 5000: CRQ initialized
[    1.449726] tpm_ibmvtpm 5000: CRQ initialization completed
[    2.483218] tpm tpm0: auth session is not active