linux-kernel - [PATCH v17 4/6] tpm: tpm_tis: Verify TPM_STS register is valid after locality request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211024164855.250362-5-amirmizi6@gmail.com>
Date:   Sun, 24 Oct 2021 19:48:53 +0300
From:   amirmizi6@...il.com
To:     Eyal.Cohen@...oton.com, jarkko@...nel.org, oshrialkoby85@...il.com,
        alexander.steffen@...ineon.com, robh+dt@...nel.org,
        mark.rutland@....com, peterhuewe@....de, jgg@...pe.ca,
        arnd@...db.de, gregkh@...uxfoundation.org, benoit.houyere@...com,
        eajames@...ux.ibm.com, joel@....id.au
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-integrity@...r.kernel.org, oshri.alkoby@...oton.com,
        tmaimon77@...il.com, gcwilson@...ibm.com, kgoldman@...ibm.com,
        Dan.Morav@...oton.com, oren.tanami@...oton.com,
        shmulik.hager@...oton.com, amir.mizinski@...oton.com,
        Amir Mizinski <amirmizi6@...il.com>
Subject: [PATCH v17 4/6] tpm: tpm_tis: Verify TPM_STS register is valid after locality request

From: Amir Mizinski <amirmizi6@...il.com>

This issue could occur when the TPM does not update TPM_STS register after
a locality request (TPM_STS Initial value = 0xFF) and a TPM_STS register
read occurs in the tpm_tis_status(chip) function call.

When a call to tpm_tis_send_data() function is made after a
request_locality() call, the condition
("if ((status & TPM_STS_COMMAND_READY) == 0)") is checked. At this moment
if the status value is 0xFF, then it is considered, wrongly, in “ready”
state (by checking only one bit). However, at this moment the TPM is, in
fact, in "Idle" state and remains in "Idle" state because
"tpm_tis_ready(chip);" was not executed.
Waiting for the condition TPM_STS.tpmGo == 0, will ensure that the TPM
status register has the correct value.

Suggested-by: Benoit Houyere <benoit.houyere@...com>
Signed-off-by: Amir Mizinski <amirmizi6@...il.com>
---
 drivers/char/tpm/tpm_tis_core.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index e1c4a5a..237b952 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -177,8 +177,14 @@ static int request_locality(struct tpm_chip *chip, int l)
 	} else {
 		/* wait for burstcount */
 		do {
-			if (check_locality(chip, l))
+			if (check_locality(chip, l)) {
+				if (wait_for_tpm_stat(chip, TPM_STS_GO, 0,
+							  chip->timeout_c,
+							  &priv->int_queue,
+							  false) < 0)
+					return -ETIME;
 				return l;
+			}
 			tpm_msleep(TPM_TIMEOUT);
 		} while (time_before(jiffies, stop));
 	}
-- 
2.7.4