Linus Torvalds, the creator of Linux, among other things, is a man with a strong opinion. On some of his recent patch notes, Torvalds has expressed his slightly-growing frustration with AMD"s fTPM (firmware Trusted Platform Module) issues and bugs. As such, he has recommended disabling it during runtime.
In case you haven"t been following, earlier this year, it was found that Linux too was now exhibiting fTPM-related stuttering and freezing issues, something that was limited to Windows only last year. The issue is related to HWRNG.
On a patch note, Torvalds writes:
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.
Later, he further adds:
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
[..]
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.
You can follow the series of messages on the Linux kernel mailing list (LKML) here.