linux-kernel - Re: [RFC PATCH 03/11] x86/boot: Allow a "silent" kaslr random byte fetch

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: <B173D69E-DC6C-4658-B5CB-391D3C6A6597@amacapital.net>
Date:   Wed, 5 Feb 2020 17:08:55 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Kristen Carlson Accardi <kristen@...ux.intel.com>
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
        arjan@...ux.intel.com, keescook@...omium.org,
        rick.p.edgecombe@...el.com, x86@...nel.org,
        linux-kernel@...r.kernel.org, kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH 03/11] x86/boot: Allow a "silent" kaslr random byte fetch

> On Feb 5, 2020, at 2:39 PM, Kristen Carlson Accardi <kristen@...ux.intel.com> wrote:
> 
> From: Kees Cook <keescook@...omium.org>
> 
> Under earlyprintk, each RNG call produces a debug report line. When
> shuffling hundreds of functions, this is not useful information (each
> line is identical and tells us nothing new). Instead, allow for a NULL
> "purpose" to suppress the debug reporting.

Have you counted how many RDRAND calls this causes?  RDRAND is exceedingly slow on all CPUs I’ve looked at. The whole “RDRAND has great bandwidth” marketing BS actually means that it has decent bandwidth if all CPUs hammer it at the same time. The latency is abysmal.  I have asked Intel to improve this, but the latency of that request will be quadrillions of cycles :)

It wouldn’t shock me if just the RDRAND calls account for a respectable fraction of total time. The RDTSC fallback, on the other hand, may be so predictable as to be useless.

I would suggest adding a little ChaCha20 DRBG or similar to the KASLR environment instead. What crypto primitives are available there?