[cryptography] Kernel space vs userspace RNG

dj at deadhat.com dj at deadhat.com
Thu May 5 14:22:42 EDT 2016

> On 05/05/16 09:40 AM, shawn wilson wrote:
>> Just reflecting on the Linux RNG thread a bit ago, is there any
>> technical reason to have RNG in kernel space?
> The procurement of an RNG source for crypto is always a *system* design
> issue.
> The expectation that a kernel offering (intended for a wide range of CPU
> architectures, each of which being deployed in its own range of systems)
> can solve this system issue is IMHO naive.
> Thus, kernel space vs user space makes little difference.
> This being said, the kernel developers appear to make good faith efforts
> to adapt to the ever evolving digital electronics paradigms prevailing
> in a few mainstream system architectures. Is this effective versus some
> criteria for RNG quality? Is this good enough for you?
> It's your duty to figure out, I guess.
> Regards,
> - Thierry Moreau

I think this sums it up well. Today you are thrown into having to know
what to do specifically because it's a system level problem (matching
entropy sources to extractors to PRNGs to consuming functions).

The OS kernel does a thing well that is it's job - taking single physical
instances of entropy sources, post processing it and making it available
to all userland and kernel consumers.

However kernel writers cannot address the full system issue because they
don't know what hardware they are running on. They don't know if they are
in a VM. They don't know whether or not they have access to entropic datao
or whether something else has access to the same data.

So one of the "things you should know" is if you run a modern Linux,
Solaris or Windows on specific CPUs in specific environments (like not in
a VM) then it can and will serve your userland programs with
cryptographically useful random numbers, at the cost of a fairly large
attack surface (drivers, APIs, kernel code, timing, memory etc.)

Intel came down firmly on the side of enabling the userland. One
instruction puts entropic state into the register of your running userland
program. Smaller attack surface, simpler, quicker, serves multiple users
whether or not they are running in on bare metal or in a VM. You have to
trust the VM (as you do for anything else you do in a VM). Stuff is done
in hardware to make sure it serves multiple consumers, just as an OS does
stuff to serve multiple consumers.

A SW userland RNG is an effective method to connect entropy sources you
know about on your system to algorithms that meet your needs. The recent
switch to NIST requiring 192 bits or greater in key strength has
precipitated a few 256 bit SW SP800-90 implementations. I know, I wrote a
couple of them and I've reviewed a few others that have been written in
response to the NIST change.

SW RNG code is also easy to take through certification.
The different is you take the system through certification, not just the
code (except for CAVS). An OS kernel writer doesn't have that advantage.

So my general view is that if you are tasked with enabling random numbers
in your application, userland is usually a better place to do it. Maybe in
a decent library used directly by your application. Maybe with some
trivial inline assembler. But only if you can control the entropy source
and the sharing of it. If you can use HW features (RdRand, RdSeed, other
entropy sources, AES-NI, Hash instructions etc.) then your SW task is
simplified, but it assumes you know what hardware you are writing for.
Ditto for other platforms I'm less familiar with.

The mistake I have seen, particularly in certain 'lightweight' SSL
libraries is to say "It's our policy not to do the RNG thing - we trust
the OS to provide entropy" and read from /dev/urandom as a result (because
/dev/random blocks on many platforms). They are trusting the thing that is
not in a place where it can guarantee entropy sources are available. It
will work on some platforms and will certainly fail on some platforms,
particularly lightweight platforms with Linux kernels on CPUs with no
deliberately designed source of entropy which is where lightweight SSL
libraries are used most.


More information about the cryptography mailing list