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]
Message-ID: <20191008212041.GA7222@amd>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ