[<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?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
