lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ