[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whqT0PxBazwfjWwoHQQFzZt50tV6Jfgq3iYceKMJtyuUg@mail.gmail.com>
Date: Fri, 28 Jul 2023 13:41:19 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Daniil Stas <daniil.stas@...teo.net>
Cc: Mario Limonciello <mario.limonciello@....com>,
James.Bottomley@...senpartnership.com, Jason@...c4.com,
jarkko@...nel.org, 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 Thu, 27 Jul 2023 at 10:05, Daniil Stas <daniil.stas@...teo.net> wrote:
>
> Here is the bug report I created:
> https://bugzilla.kernel.org/show_bug.cgi?id=217719
Let's just disable the stupid fTPM hwrnd thing.
Maybe use it for the boot-time "gather entropy from different
sources", but clearly it should *not* be used at runtime.
Why would anybody use that crud when any machine that has it
supposedly fixed (which apparently didn't turn out to be true after
all) would also have the CPU rdrand instruction that doesn't have the
problem?
If you don't trust the CPU rdrand implementation (and that has had
bugs too - see clear_rdrand_cpuid_bit() and x86_init_rdrand()), why
would you trust the fTPM version that has caused even *more* problems?
So I don't see any downside to just saying "that fTPM thing is not
working". Even if it ends up working in the future, there are
alternatives that aren't any worse.
Linus
Powered by blists - more mailing lists