Am Samstag, 2. November 2013, 12:01:13 schrieb Pavel Machek:
Hi Pavel,
Hi!
sense of where the unpredictability might be coming from, and
whether
the unpredictability is coming from something which is fundamentally
arising from something which is chaotic or quantum effect, or just
because
On Sun, Nov 03, 2013 at 08:20:34AM +0100, Stephan Mueller wrote:
Another friend of mine mentioned that he assumes the rise and fall times
of transistors varies very slightly and could be the main reason for the
jitter. I do not think that this is really the case, because our gates
that form
Print a notification to the console when the nonblocking pool is
initialized. Also printk a warning when a process tries reading from
/dev/urandom before it is fully initialized.
Signed-off-by: Theodore Ts'o ty...@mit.edu
---
drivers/char/random.c | 12 +++-
1 file changed, 11
The rand_initialize() function was being run fairly late in the kernel
boot sequence. This was unfortunate, since it zero'ed the entropy
counters, thus throwing away credit that was accumulated earlier in
the boot sequence, and it also meant that initcall functions run
before rand_initialize were
Change add_timer_randomness() so that it directs incoming entropy to
the nonblocking pool first if it hasn't been fully initialized yet.
This matches the strategy we use in add_interrupt_randomness(), which
allows us to push the randomness where we need it the most during when
the system is first
Some investigation from FreeBSD shows that there is entropy available
from measuring the device attach times:
http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
This will hopefully help us more quickly initialize the entropy pools
while the system is booting (which is one
These patches improve how /dev/random initializes its entropy pool
during the kernel boot sequence. With these changes, using an x86 test
kernel run under KVM, the urandom pool gets initialized before the init
scripts start running, and of the kernel users of get_random_bytes(), a
debugging
On Sun, Nov 03, 2013 at 08:33:12AM -0500, Theodore Ts'o wrote:
Some investigation from FreeBSD shows that there is entropy available
from measuring the device attach times:
http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
This will hopefully help us more quickly
On Sun, Nov 03, 2013 at 06:51:18AM -0800, Greg KH wrote:
Is it an issue that dev-devt will almost always be 0,0 for this
function call? Why not use the name instead here, that's more unique
and every device has one, not just a tiny %.
Hmm, good point. Thanks for raising it. I'll make this
On Sun, Nov 03, 2013 at 08:33:12AM -0500, Theodore Ts'o wrote:
Some investigation from FreeBSD shows that there is entropy available
from measuring the device attach times:
http://lists.randombit.net/pipermail/cryptography/2013-October/005689.html
This will hopefully help us more quickly
Hi!
Another friend of mine mentioned that he assumes the rise and fall times
of transistors varies very slightly and could be the main reason for the
jitter. I do not think that this is really the case, because our gates
that form the CPU instructions comprise of many transistors. The
When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.
Signed-off-by: Kees Cook keesc...@chromium.org
---
Added
12 matches
Mail list logo
