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
---
Added linux-crypto list to CC.
---
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
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 quic
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 t
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 quic
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
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 b
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 printk
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"
---
drivers/char/random.c | 12 +++-
1 file changed, 11 insertions(+), 1 dele
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
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 f
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 ju
12 matches
Mail list logo
