Matt Mackall a écrit :
On Tue, Dec 04, 2007 at 07:17:58PM +0100, Eric Dumazet wrote:
Alan Cox a ?crit :
No matter what you consider as being better, changing a 12 years old and
widely used userspace interface like /dev/urandom is simply not an
option.
Fixing it to be more efficient in its use of entropy and also fixing the
fact its not actually a good random number source would be worth looking
at however.
Yes, since current behavior on network irq is very pessimistic.
No, it's very optimistic. The network should not be trusted.
You keep saying that. I am refering to your previous attempts last year to
remove net drivers from sources of entropy. No real changes were done.
If the network should not be trusted, then a patch should make sure network
interrupts feed /dev/urandom but not /dev/random at all. (ie not calling
credit_entropy_store() at all)
The distinction between /dev/random and /dev/urandom boils down to one
word: paranoia. If you are not paranoid enough to mistrust your
network, then /dev/random IS NOT FOR YOU. Use /dev/urandom. Do not
send patches to make /dev/random less paranoid, kthxbye.
I have many tg3 adapters on my servers, receiving thousand of interrupts per
second, and calling add_timer_randomness(). I would like to either :
- Make sure this stuff is doing usefull job.
- Make improvements to reduce cpu time used.
I do not use /dev/urandom or/and /dev/random, but I know David wont accept a
patch to remove IRQF_SAMPLE_RANDOM from tg3.c
Currently, I see that current implementation is suboptimal because it calls
credit_entropy_store( nbits=0) forever.
If you have some trafic, (ie more than HZ/2 interrupts per second),
then add_timer_randomness() feeds
some entropy but gives no credit (calling credit_entropy_store() with
nbits=0)
This is because we take into account only the jiffies difference, and
not the get_cycles() that should give
us more entropy on most plaforms.
If we cannot measure a difference, we should nonetheless assume there
is one?
There is a big difference on get_cycles() and jiffies. You should try to
measure it on a typical x86_64 platform.
In this patch, I suggest that we feed only one u32 word of entropy,
combination of the previous distinct
words (with some of them being constant or so), so that the nbits
estimation is less pessimistic, but also to
avoid injecting false entropy.
Umm.. no, that's not how it works at all.
Also, for future reference, patches for /dev/random go through me, not
through Dave.
Why ? David is the network maintainer, and he was the one who rejected your
previous patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
