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: <20190814232434.GA31769@amd>
Date:   Thu, 15 Aug 2019 01:24:35 +0200
From:   Pavel Machek <pavel@....cz>
To:     "Lendacky, Thomas" <Thomas.Lendacky@....com>, tytso@....edu,
        nhorman@...driver.com
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Chen Yu <yu.c.chen@...el.com>, Jonathan Corbet <corbet@....net>
Subject: Non-random RDRAND Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on
 AMD family 15h/16h

On Wed 2019-08-14 21:17:41, Lendacky, Thomas wrote:
> From: Tom Lendacky <thomas.lendacky@....com>
> 
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from BIOS
> not performing the proper steps during resume to ensure RDRAND continues
> to function properly.

Burn it with fire!

I mean... people were afraid RDRAND would be backdoored, and you now
confirm ... it indeed _is_ backdoored? /., here's news for you!

So what is the impact? Does it give random-looking but predictable
numbers after resume? Does it give all zeros? Something else?

>  
> +	rdrand_force	[X86]
> +			On certain AMD processors, the advertisement of the
> +			RDRAND instruction has been disabled by the kernel
> +			because of buggy BIOS support, specifically around the
> +			suspend/resume path. This option allows for overriding
> +			that decision if it is known that the BIOS support for
> +			RDRAND is not buggy on the system.

But this is not how we normally deal with buggy BIOSes. We don't want
user to have to decide this...

Should we introduce black-list or white-list of BIOS versions?

Hmm. Actually.

You are the CPU vendor. Surely you can tell us how to init RDRAND in
kernel if BIOS failed to do that... can you?

									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