[Cryptography] Bizarre "latent entropy" kernel patch

[John Gilmore]

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).

  At the very least, this plugin is a much more comprehensive example
  for how to manipulate kernel code using the gcc plugin internals"

* tag 'gcc-plugins-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  latent_entropy: Mark functions with __latent_entropy
  gcc-plugins: Add latent_entropy plugin

The patch adds a bunch of "__attribute__((latent_entropy))" tags to
various kernel functions and data structures, then adds a plugin to
the GCC compiler itself.  That plugin uses those attributes to insert
extra, invisible code into each tagged function, which appears to use
XOR or ADD to add a different pseudo-random constant to a 64-bit
global variable, whenever a different execution path is taken in a
tagged function.  (I.e. each side of an "if" statement dumps in a
different "random-looking" constant.)

It's not designed to be cryptographically secure.  It's not designed
to be secure at all.  It almost looks like security-by-obscurity,
like calculating the resulting 64-bit number would be so cumbersome
that "most attackers won't bother".

I *think* the design goal is to make the address space layout
different, on every different piece of hardware that identical kernels
boot on, and probably different every time you boot an identical
kernel on the same piece of hardware (if it's feeding in the realtime
clock value, for example, which is not in this patch, but is perhaps
done elsewhere).

This non-cryptographically-secure non-random 'randomness' seems to be
collected solely so that it can be fed into the long-existing Address
Space Layout Randomization code, which makes it hard for heap-overflow
or stack-overflow attacks to know where anything is in the address
space.

Of course, neither the code, nor its sketchy documentation, actually
says that anywhere!

If anybody actually knows the motivation for this bizarre
implementation, don't just let us know -- improve the documentation!
Which currently just says:

config GCC_PLUGIN_LATENT_ENTROPY
+      bool "Generate some entropy during boot and runtime"
+      depends on GCC_PLUGINS
+      help
+        By saying Y here the kernel will instrument some kernel code to
+	 extract some entropy from both original and artificially created
+	 program state.  This will help especially embedded systems where
+	 there is little 'natural' source of entropy normally.  The cost
+	 is some slowdown of the boot process (about 0.5%) and fork and
+	 irq processing.
+
+	 Note that entropy extracted this way is not cryptographically
+	 secure!
+
+	 This plugin was ported from grsecurity/PaX. More information at:
+	     * https://grsecurity.net/
+	     * https://pax.grsecurity.net/

The "grsecurity.net" site is reasonable to examine.  The
"pax.grsecurity.net" site is totally unreadable to anyone who
doesn't already know what it is about (which includes me).
It desperately needs an introductory paragraph, or an "About" link
that works!  By trolling around in there I did find this general
description of what they think they're up to:

  https://pax.grsecurity.net/docs/pax.txt

	John