Re: [PATCH] dmi: Feed DMI table to /dev/random driver

[Theodore Ts'o]

On Fri, Jul 20, 2012 at 01:15:20PM -0700, Tony Luck wrote:
> Send the entire DMI (SMBIOS) table to the /dev/random driver to
> help seed its pools.
> 
> Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx>
> ---
> 
> This looks a useful addition to your /dev/random series. There are
> lots of platform specific goodies in this table (BIOS version, system
> serial number and UUID, count and version number of processors, DIMM
> slot population and serial numbers, etc.)
> 
> On the system I tested the patch on the table is 9866 bytes. Is it
> OK to dump that much into add_device_randomness() in one shot? The
> alternative is to select the 'useful' bits deeper into the routines
> that parse the entries in the table.
> 
>  drivers/firmware/dmi_scan.c | 3 +++
>  1 file changed, 3 insertions(+)

This was something I was looking at doing, but I had considered the
approach you used, and had abandoned it because dmi_walk_early() gets
called ultimately via the setup_arch() call, and the random pools only
get initialized much later in the boot process.  

The fact that you didn't crash when you tested it is simply because
we're not allocating any memory or initializing any criticla data
structures in rand_initialize().  (We used to, but not any more.)

I'm a little nervous enshrining the fact that it's OK to call the
random driver before rand_initialize is called(), but it does work
today.  If we are going to do this, we need to put a big fat comment
in front of rand_initialize() indicating that it's important that we
not depend on any data structures getting initialized by
rand_initialize() before it's safe to call add_device_randomness().

The other approach was to add some new interface that random.c would
call which would grab the dmi data from rand_initialize().  But that's
going to be a lot more complicated, so I guess we should go with the
simple/stupid approach.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/