[Cryptography] Bizarre "latent entropy" kernel patch

[Ray Dillinger]

On 03/01/2017 01:17 PM, John Gilmore wrote:
> While poking around at recent kernel patches, I found this one:
> 
>   Merge tag 'gcc-plugins-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
>   https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9ffc66941df278c9f4df979b6bcf6c6ddafedd16
> 
> Pull gcc plugins update from Kees Cook:
>  "This adds a new gcc plugin named "latent_entropy". It is designed to
>   extract as much possible uncertainty from a running system at boot
>   time as possible, hoping to capitalize on any possible variation in
>   CPU operation (due to runtime data differences, hardware differences,
>   SMP ordering, thermal timing variation, cache behavior, etc).

It appears to be an attempt to solve or at least workaround the problem
of memory-layout randomization prior to actually loading the filesystem
and getting access to /dev/random.

I think that it will be a bit better for that purpose than
security-by-obscurity; many of the branches it co-opts to side effect
itself will depend on genuine sources of entropy such as timing,
temperature, etc.  But most are deterministic.

It doesn't gather as many bits of "real" randomness as we'd like.  The
search space is probably smaller than 2^32 of the 64-bit entries, though
I haven't done an extensive analysis.

They might have done better by linking some of the already-debugged
entropy collection code that's in the /dev/random drivers.  But (I
think) most of that code depends on the filesystem and runtime already
being mounted, so using that would be hard.

It will not be as good as /dev/random, but it will add a work factor to
schemes that depend on exploiting memory layout.  It's better than many
of the possible alternatives, I think, but not so good as to justify
ceasing to look for a better solution.

And now the kernel has its own tiny little limited-use substandard
entropy pool....  which probably shouldn't get used for anything else
once the kernel and services are running.

				Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170301/ef1dd4de/attachment.sig>