[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190828103113.GA14677@amd>
Date: Wed, 28 Aug 2019 12:31:13 +0200
From: Pavel Machek <pavel@...x.de>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Pavel Machek <pavel@...x.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Tom Lendacky <thomas.lendacky@....com>,
Borislav Petkov <bp@...e.de>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Chen Yu <yu.c.chen@...el.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Jonathan Corbet <corbet@....net>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Juergen Gross <jgross@...e.com>,
Kees Cook <keescook@...omium.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Nathan Chancellor <natechancellor@...il.com>,
Paolo Bonzini <pbonzini@...hat.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 4.19 72/98] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD
family 15h/16h
On Tue 2019-08-27 15:30:30, Thomas Gleixner wrote:
> On Tue, 27 Aug 2019, Pavel Machek wrote:
>
> > On Tue 2019-08-27 09:50:51, Greg Kroah-Hartman wrote:
> > > From: Tom Lendacky <thomas.lendacky@....com>
> > >
> > > commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 upstream.
> > >
> > > There have been reports of RDRAND issues after resuming from suspend on
> > > some AMD family 15h and family 16h systems. This issue stems from a BIOS
> > > not performing the proper steps during resume to ensure RDRAND continues
> > > to function properly.
> >
> > Yes. And instead of reinitializing the RDRAND on resume, this patch
> > breaks support even for people with properly functioning BIOSes...
>
> There is no way to reinitialize RDRAND from the kernel otherwise we would
> have exactly done that. If you know how to do that please tell.
Would they? AMD is not exactly doing good job with communication
here. If BIOS can do it, kernel can do it, too... or do you have
information saying otherwise?
> Also disabling it for every BIOS is the only way which can be done because
> there is no way to know whether the BIOS is fixed or not at cold boot
> time. And it has to be known there because applications cache the
I'm pretty sure DMI-based whitelist would help here. It should be
reasonably to fill it with the common machines at least.
Plus, where is the CVE, and does AMD do anything to make BIOS vendors
fix them?
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists