linux-kernel - Re: [regression] Bug 216989 - since 6.1 systems with AMD Ryzen stutter when fTPM is enabled

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]

Date:   Tue, 7 Feb 2023 23:31:37 -0300
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Linux regressions mailing list <regressions@...ts.linux.dev>,
        Peter Huewe <peterhuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        linux-integrity@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>, reach622@...lcuk.com,
        1138267643@...com
Subject: Re: [regression] Bug 216989 - since 6.1 systems with AMD Ryzen
 stutter when fTPM is enabled

On Tue, Feb 7, 2023 at 11:13 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
>
> On Wed, Feb 08, 2023 at 04:13:16AM +0200, Jarkko Sakkinen wrote:
> > On Thu, Feb 02, 2023 at 07:57:37AM -0500, James Bottomley wrote:
> > > On Thu, 2023-02-02 at 11:28 +0100, Linux kernel regression tracking
> > > (Thorsten Leemhuis) wrote:
> > > [...]
> > > > So it's a firmware problem, but apparently one that Linux only
> > > > triggers since 6.1.
> > > >
> > > > Jason, could the hwrng changes have anything to do with this?
> > > >
> > > > A bisection really would be helpful, but I guess that is not easy as
> > > > the problem apparently only shows up after some time...
> > >
> > > the problem description says the fTPM causes system stutter when it
> > > writes to NVRAM.  Since an fTPM is a proprietary implementation, we
> > > don't know what it does.  The ms TPM implementation definitely doesn't
> > > trigger NV writes on rng requests, but it is plausible this fTPM does
> > > ... particularly if they have a time based input to the DRNG.  Even if
> > > this speculation is true, there's not much we can do about it, since
> > > it's a firmware bug and AMD should have delivered the BIOS update that
> > > fixes it.
> > >
> > > The way to test this would be to set the config option
> > >
> > > CONFIG_HW_RANDOM_TPM=n
> > >
> > > and see if the stutter goes away.  I suppose if someone could quantify
> > > the bad bioses, we could warn, but that's about it.
> > >
> > > James
> > >
> >
> > And e.g. I do not have a Ryzen CPU so pretty hard to answer such question.
>
> ... about hwrng

Well, the options here are basically:

a) Do nothing, and just expect people to update their BIOSes, since an
update is available.
b) Do nothing, and expect people with broken BIOSes to `echo blacklist
tpm >> /etc/modprobesomethingsomething`.
c) Figure out how to identify the buggy BIOS and disable the TPM's rng
with a quirk in this case.
d) Figure out how to dynamically detect TPM rng latency, and warn about it.
e) Figure out how to dynamically detect TPM rng latency, and disable it.

I think given that a firmware update *is* available, (a) is fine. And
the generic workaround remains (b). But if you want to be really nice,
(c) would be fine too. Somebody with the affected hardware would
probably have to send in some DMI logs or whatever else. (d) and (e)
sound possible in theory but I dunno really... seems finicky.

Jason