[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whphk8Jp=NYmnm7Qv+vZ6ScYCz+rV8a2G1nD-AQY3z+mQ@mail.gmail.com>
Date: Mon, 31 Jul 2023 12:05:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Daniil Stas <daniil.stas@...teo.net>,
Mario Limonciello <mario.limonciello@....com>,
James.Bottomley@...senpartnership.com, Jason@...c4.com,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
regressions@...mhuis.info, stable@...r.kernel.org
Subject: Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs
On Mon, 31 Jul 2023 at 03:53, Jarkko Sakkinen <jarkko@...nel.org> wrote:
>
> I quickly carved up a patch (attached), which is only compile tested
> because I do not have any AMD hardware at hand.
Is there some way to just see "this is a fTPM"?
Because honestly, even if AMD is the one that has had stuttering
issues, the bigger argument is that there is simply no _point_ in
supporting randomness from a firmware source.
There is no way anybody should believe that a firmware TPM generates
better randomness than we do natively.
And there are many reasons to _not_ believe it. The AMD problem is
just the most user-visible one.
Now, I'm not saying that a fTPM needs to be disabled in general - but
I really feel like we should just do
static int tpm_add_hwrng(struct tpm_chip *chip)
{
if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
return 0;
// If it's not hardware, don't treat it as such
if (tpm_is_fTPM(chip))
return 0;
[...]
and be done with it.
But hey, if we have no way to see that whole "this is firmware
emulation", then just blocking AMD might be the only way.
Linus
Powered by blists - more mailing lists