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@posteo.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

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@linux.ibm....

[3] https://lore.kernel.org/lkml/20230623030427.908-1-mario.limonciello@amd.com/