Re: [PATCH 1/2] random: Add support for architectural random hooks

[Matt Mackall <mpm@selenic.com>]

On Fri, 2011-07-29 at 13:37 -0700, H. Peter Anvin wrote:
> From: "H. Peter Anvin" <hpa@linux.intel.com>
> 
> Add support for architecture-specific hooks into either the blocking
> or the nonblocking random pools.  These hooks are defined to return
> the number of bytes of randomness produced (similar to a read() system
> call.)  They could also potentialy be used to inject randomness on
> demand while continuing to use the pool system, by calling a suitable
> injection interface and returning 0.

I have already NAKed this approach in no uncertain terms.

What if the next fancy hardware RNG with its own crypto hardening[1]
that shows up is not a special CPU instruction or indeed not even
arch-specific? It could just as easily be a USB or i2c or PCI device.
There's no reason to think the two notions are connected AT ALL. Your
whole notion of an 'architectural random source' is just plain wrong.
The right way to do this is to add a generic extension to the existing
hardware RNG design.

If you want to make forward progress, spend the half a day to implement
a standard HWRNG driver so people with your hardware have basic
functionality, then come back and we'll discuss implementing a trusted
fast path API to HWRNG drivers. If you had done this weeks ago when I
first asked you to do that, you would have had no problem getting basic
support into the current merge window.

[1] hopefully auditable without an electron microscope!
-- 
Mathematics is the supreme nostalgia of our time.