linux-kernel - Re: [tip: x86/urgent] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 8 Oct 2019 23:20:41 +0200
From:   Pavel Machek <pavel@....cz>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, stable@...r.kernel.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Juergen Gross <jgross@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>, Chen Yu <yu.c.chen@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Borislav Petkov <bp@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [tip: x86/urgent] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD
 family 15h/16h

Hi!

> >> x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h
> >>
> >> 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.
> > 
> > There are quite a few unanswered questions here.
> > 
> > a) Is there/should there be CVE for this?
> > 
> > b) Can we perform proper steps in kernel, thus making RDRAND usable
> > even when BIOS is buggy?
> > 
> 
> The kernel should at least be able to set its internal "CPUID" bit, visible
> through /proc/cpuinfo.

Actually, with hindsight I see two possible improvements here:

1) Not having enabled s2ram in config does not mean machine was not
suspended/resumed, then new kernel executed via kexec.

2) We really can continue using the RDRAND: we know how it fails
(constant pattern) so we can check for the failure in kernel, and can
continue to use it... It will certainly work until first suspend, and
there's good chance it will work after that, too. (We still need to
prevent userspace from using it).

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)