linux-toradex.git/drivers, branch v2.6.32.60

dmi: Feed DMI table to /dev/random driver

2012-10-07T21:41:23+00:00

commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.

Signed-off-by: Tony Luck 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

mfd: wm831x: Feed the device UUID into device_add_randomness()

2012-10-07T21:41:23+00:00

commit 27130f0cc3ab97560384da437e4621fc4e94f21c upstream.

wm831x devices contain a unique ID value. Feed this into the newly added
device_add_randomness() to add some per device seed data to the pool.

Signed-off-by: Mark Brown 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

rtc: wm831x: Feed the write counter into device_add_randomness()

2012-10-07T21:41:22+00:00

commit 9dccf55f4cb011a7552a8a2749a580662f5ed8ed upstream.

The tamper evident features of the RTC include the "write counter" which
is a pseudo-random number regenerated whenever we set the RTC. Since this
value is unpredictable it should provide some useful seeding to the random
number generator.

Only do this on boot since the goal is to seed the pool rather than add
useful entropy.

Signed-off-by: Mark Brown 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: Add comment to random_initialize()

2012-10-07T21:41:21+00:00

commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream.

Many platforms have per-machine instance data (serial numbers,
asset tags, etc.) squirreled away in areas that are accessed
during early system bringup. Mixing this data into the random
pools has a very high value in providing better random data,
so we should allow (and even encourage) architecture code to
call add_device_randomness() from the setup_arch() paths.

However, this limits our options for internal structure of
the random driver since random_initialize() is not called
until long after setup_arch().

Add a big fat comment to rand_initialize() spelling out
this requirement.

Suggested-by: Theodore Ts'o 
Signed-off-by: Tony Luck 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: remove rand_initialize_irq()

2012-10-07T21:41:21+00:00

commit c5857ccf293968348e5eb4ebedc68074de3dcda6 upstream.

With the new interrupt sampling system, we are no longer using the
timer_rand_state structure in the irq descriptor, so we can stop
initializing it now.

[ Merged in fixes from Sedat to find some last missing references to
  rand_initialize_irq() ]

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Sedat Dilek 
[PG: in .34 the irqdesc.h content is in irq.h instead.]
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

usb: feed USB device information to the /dev/random driver

2012-10-07T21:41:20+00:00

commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream.

Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.

Cc: Linus Torvalds 
Acked-by: Greg KH 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: mix in architectural randomness in extract_buf()

2012-10-07T21:41:18+00:00

commit d2e7c96af1e54b507ae2a6a7dd2baf588417a7e5 upstream.

Mix in any architectural randomness in extract_buf() instead of
xfer_secondary_buf().  This allows us to mix in more architectural
randomness, and it also makes xfer_secondary_buf() faster, moving a
tiny bit of additional CPU overhead to process which is extracting the
randomness.

[ Commit description modified by tytso to remove an extended
  advertisement for the RDRAND instruction. ]

Signed-off-by: H. Peter Anvin 
Acked-by: Ingo Molnar 
Cc: DJ Johnston 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: add new get_random_bytes_arch() function

2012-10-07T21:41:18+00:00

commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.

Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present.  Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.

The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door.  (For example, an
increasing counter encrypted by an AES key known to the NSA.)

It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
 --- especially since Bull Mountain is documented to use AES as a
whitener.  Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel.  Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.

Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.

This way we get almost of the benefits of the HW RNG without any
potential liabilities.  The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.

For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: use the arch-specific rng in xfer_secondary_pool

2012-10-07T21:41:17+00:00

commit e6d4947b12e8ad947add1032dd754803c6004824 upstream.

If the CPU supports a hardware random number generator, use it in
xfer_secondary_pool(), where it will significantly improve things and
where we can afford it.

Also, remove the use of the arch-specific rng in
add_timer_randomness(), since the call is significantly slower than
get_cycles(), and we're much better off using it in
xfer_secondary_pool() anyway.

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau

random: create add_device_randomness() interface

2012-10-07T21:41:17+00:00

commit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream.

Add a new interface, add_device_randomness() for adding data to the
random pool that is likely to differ between two devices (or possibly
even per boot).  This would be things like MAC addresses or serial
numbers, or the read-out of the RTC. This does *not* add any actual
entropy to the pool, but it initializes the pool to different values
for devices that might otherwise be identical and have very little
entropy available to them (particularly common in the embedded world).

[ Modified by tytso to mix in a timestamp, since there may be some
  variability caused by the time needed to detect/configure the hardware
  in question. ]

Signed-off-by: Linus Torvalds 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Willy Tarreau