kernel/linux.git/drivers/char/random.c, branch linux-2.6.35.y

random: simplify fips mode

2010-05-20T09:55:01+00:00

Rather than dynamically allocate 10 bytes, move it to static allocation. This saves space and avoids the need for error checking. Signed-off-by: Matt Mackall Signed-off-by: Herbert Xu

Fix misspellings of "truly" in comments.

2010-02-04T10:55:45+00:00

Some comments misspell "truly"; this fixes them. No code changes. Signed-off-by: Adam Buchbinder Signed-off-by: Jiri Kosina

random: Remove unused inode variable

2010-02-01T19:50:27+00:00

The previous changeset left behind an unused inode variable. This patch removes it. Reported-by: Stephen Rothwell Signed-off-by: Herbert Xu

random: drop weird m_time/a_time manipulation

2010-02-01T19:50:23+00:00

No other driver does anything remotely like this that I know of except for the tty drivers, and I can't see any reason for random/urandom to do it. In fact, it's a (trivial, harmless) timing information leak. And obviously, it generates power- and flash-cycle wasting I/O, especially if combined with something like hwrngd. Also, it breaks ubifs's expectations. Signed-off-by: Matt Mackall Signed-off-by: Herbert Xu

random.c: use %pU to print UUIDs

2009-12-15T16:53:33+00:00

Signed-off-by: Joe Perches Acked-by: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sysctl: Drop & in front of every proc_handler.

2009-11-18T16:37:40+00:00

For consistency drop & in front of every proc_handler. Explicity taking the address is unnecessary and it prevents optimizations like stubbing the proc_handlers to NULL. Cc: Alexey Dobriyan Cc: Ingo Molnar Cc: Joe Perches Signed-off-by: Eric W. Biederman

sysctl drivers: Remove dead binary sysctl support

2009-11-12T10:04:58+00:00

Now that sys_sysctl is a wrapper around /proc/sys all of the binary sysctl support elsewhere in the tree is dead code. Cc: Jens Axboe Cc: Corey Minyard Cc: Greg Kroah-Hartman Cc: Matt Mackall Cc: Herbert Xu Cc: Neil Brown Cc: "James E.J. Bottomley" Acked-by: Clemens Ladisch for drivers/char/hpet.c Signed-off-by: Eric W. Biederman

sysctl: remove "struct file *" argument of ->proc_handler

2009-09-24T14:21:04+00:00

It's unused. It isn't needed -- read or write flag is already passed and sysctl shouldn't care about the rest. It _was_ used in two places at arch/frv for some reason. Signed-off-by: Alexey Dobriyan Cc: David Howells Cc: "Eric W. Biederman" Cc: Al Viro Cc: Ralf Baechle Cc: Martin Schwidefsky Cc: Ingo Molnar Cc: "David S. Miller" Cc: James Morris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

random: Add optional continuous repetition test to entropy store based rngs

2009-06-18T11:50:21+00:00

FIPS-140 requires that all random number generators implement continuous self tests in which each extracted block of data is compared against the last block for repetition. The ansi_cprng implements such a test, but it would be nice if the hw rng's did the same thing. Obviously its not something thats always needed, but it seems like it would be a nice feature to have on occasion. I've written the below patch which allows individual entropy stores to be flagged as desiring a continuous test to be run on them as is extracted. By default this option is off, but is enabled in the event that fips mode is selected during bootup. Signed-off-by: Neil Horman Acked-by: Matt Mackall Signed-off-by: Herbert Xu

Avoid ICE in get_random_int() with gcc-3.4.5

2009-05-19T18:25:35+00:00

Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch Cc: Matt Mackall Cc: Ingo Molnar Signed-off-by: Linus Torvalds