linux-kernel - Re: [PATCH 1/1] tpm: disable hwrng for fTPM on some AMD designs

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b157706f-b9e3-7c97-fd7c-594928d9a457@amd.com>
Date:   Fri, 28 Jul 2023 16:47:52 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Daniil Stas <daniil.stas@...teo.net>,
        James.Bottomley@...senpartnership.com, Jason@...c4.com,
        jarkko@...nel.org, 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/28/2023 4:38 PM, Linus Torvalds wrote:
> On Fri, 28 Jul 2023 at 14:01, Limonciello, Mario
> <mario.limonciello@....com> wrote:
>>
>> That's exactly why I was asking in the kernel bugzilla if something
>> similar gets tripped up by RDRAND.
> 
> So that would sound very unlikely, but who knows... Microcode can
> obviously do pretty much anything at all, but at least the original
> fTPM issues _seemed_ to be about BIOS doing truly crazy things like
> SPI flash accesses.
> 
> I can easily imagine a BIOS fTPM code using some absolutely horrid
> global "EFI synchronization" lock or whatever, which could then cause
> random problems just based on some entirely unrelated activity.
> 
> I would not be surprised, for example, if wasn't the fTPM hwrnd code
> itself that decided to read some random number from SPI, but that it
> simply got serialized with something else that the BIOS was involved
> with. It's not like BIOS people are famous for their scalable code
> that is entirely parallel...
> 
> And I'd be _very_ surprised if CPU microcode does anything even
> remotely like that. Not impossible - HP famously screwed with the time
> stamp counter with SMIs, and I could imagine them - or others - doing
> the same with rdrand.
> 
> But it does sound pretty damn unlikely, compared to "EFI BIOS uses a
> one big lock approach".
> 
> So rdrand (and rdseed in particular) can be rather slow, but I think
> we're talking hundreds of CPU cycles (maybe low thousands). Nothing
> like the stuttering reports we've seen from fTPM.
> 
>                              Linus

Your theory sounds totally plausible and it would explain why even 
though this system has the fixes from the original issue it's tripping a 
similar behavior.

Based on the argument of RDRAND being on the same SOC I think it's a 
pretty good argument to drop contributing to the hwrng entropy 
*anything* that's not a dTPM.