2023-08-03 03:11:01

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH 0/3] More changes related to TPM RNG handling

Patch 1 fixes a mistake in error handling path introduced in
previous patch. It should fold in previous patch or go to -fixes.

Patches 2 and 3 add command line option and drop Kconfig.
These should be targeted for -next.
Mario Limonciello (3):
tpm: Add a missing check for TPM_CHIP_FLAG_HWRNG_DISABLED
tpm: Add command line for not trusting tpm for RNG
tpm: Drop CONFIG_HW_RANDOM_TPM

Documentation/admin-guide/kernel-parameters.txt | 5 +++++
drivers/char/tpm/Kconfig | 11 -----------
drivers/char/tpm/tpm-chip.c | 17 ++++++++++++++---
3 files changed, 19 insertions(+), 14 deletions(-)

--
2.34.1



2023-08-03 03:27:19

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH 2/3] tpm: Add command line for not trusting tpm for RNG

The kernel supports random.cpu=off and random.bootloader=off.
As TPM RNG is also registered as a hwrng, add the ability to
prevent registering the TPM RNG.

Suggested-by: Mateusz Schyboll <[email protected]>
Signed-off-by: Mario Limonciello <[email protected]>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
drivers/char/tpm/tpm-chip.c | 10 ++++++++++
2 files changed, 15 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a1457995fd41c..9ff602c09f55c 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4672,6 +4672,11 @@
passed by the bootloader (if available) to
initialize the kernel's RNG.

+ random.trust_tpm=off
+ [KNL] Disable trusting the use of the TPM's
+ random number generator (if available) to
+ initialize the kernel's RNG.
+
randomize_kstack_offset=
[KNL] Enable or disable kernel stack offset
randomization, which provides roughly 5 bits of
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 8f61b784810d6..8fb42232bd7a5 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -32,6 +32,13 @@ struct class *tpm_class;
struct class *tpmrm_class;
dev_t tpm_devt;

+static bool trust_tpm __initdata = true;
+static int __init parse_trust_tpm(char *arg)
+{
+ return kstrtobool(arg, &trust_tpm);
+}
+early_param("random.trust_tpm", parse_trust_tpm);
+
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
@@ -523,6 +530,9 @@ static int tpm_hwrng_read(struct hwrng *rng, void *data, size_t max, bool wait)

static int tpm_add_hwrng(struct tpm_chip *chip)
{
+ if (!trust_tpm)
+ chip->flags |= TPM_CHIP_FLAG_HWRNG_DISABLED;
+
if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM) || tpm_is_firmware_upgrade(chip) ||
chip->flags & TPM_CHIP_FLAG_HWRNG_DISABLED)
return 0;
--
2.34.1


2023-08-03 14:11:13

by Jason A. Donenfeld

[permalink] [raw]
Subject: Re: [PATCH 2/3] tpm: Add command line for not trusting tpm for RNG

On Wed, Aug 02, 2023 at 08:50:14PM -0500, Mario Limonciello wrote:
> The kernel supports random.cpu=off and random.bootloader=off.
> As TPM RNG is also registered as a hwrng, add the ability to
> prevent registering the TPM RNG.

Please do *not* do this. I agree with Jarkko that this doesn't belong.

Firstly, you're proposing a flag for the tpm driver, so the `random.`
namespace is inappropriate. Do not use the `random.` namespace if you're
not dealing with random.c specifically. Rather, this is very much a
`tpm.register_hwrng=1/0` flag, which describes better what this is about.

Secondly, I think you're making a mountain out of a molehill. You first
wanted to also disable Intel devices too, even though they aren't
affected by this bug. Now you're proposing a way for users to disable
everything. But so far there's no evidence that this matter goes any
further than AMD's fTPM. So let's calm a bit and not make too big deal
of this. If we suddenly get lots of reports that there's broken behavior
across the board, then maybe we should consider something like this. But
insofar as this is just an AMD derp, let's keep it simple and not over
complicate everything with more knobs. Fewer knobs, please!

Finally, with regards to AMD, my hope is that eventually the fTPM
becomes useful as a hwrng, and then we can relax the disabling to
re-enable it for whatever new revision might come to exist in the
future.

Thanks,
Jason