[<prev] [next>] [day] [month] [year] [list]
Message-ID: <f9ae26a4-25f6-bf19-9d20-e28eb22c04ee@amd.com>
Date: Mon, 31 Jul 2023 16:44:06 -0500
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Jarkko Sakkinen <jarkko@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Daniil Stas <daniil.stas@...teo.net>
Cc: 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 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@...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
>
> 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.com/
[3]
https://lore.kernel.org/lkml/20230623030427.908-1-mario.limonciello@amd.com/
Powered by blists - more mailing lists