On 7/31/2023 5:53 AM, Jarkko Sakkinen wrote:
On Fri Jul 28, 2023 at 8:41 PM UTC, Linus Torvalds wrote:
On Thu, 27 Jul 2023 at 10:05, Daniil Stas <daniil.stas@xxxxxxxxxx> 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
I quickly carved up a patch (attached), which is only compile tested
because I do not have any AMD hardware at hand.
BR, Jarkko
I'll get some testing done on this patch with some AMD reference
hardware, but off the cuff comments:
1) It needs to target older stable than 6.3 because 6.1-rc1 is when
b006c439d58d was introduced and 6.1.19 backported f1324bbc4 as dc64dc4c8.
2) Add a Link tag for [1]
3) The fix for [2] is lost. The one that landed upstream was
ecff6813d2bc ("tpm: return false from tpm_amd_is_rng_defective on
non-x86 platforms").
I sent another one that checked for chip->ops [3], but this wasn't
picked up.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=217719
[2]
https://lore.kernel.org/lkml/99B81401-DB46-49B9-B321-CF832B50CAC3@xxxxxxxxxxxxx/
[3]
https://lore.kernel.org/lkml/20230623030427.908-1-mario.limonciello@xxxxxxx/
