Austin S. Hemmelgarn wrote on 2016/05/25 08:39 -0400:
On 2016-05-25 07:11, David Sterba wrote:
On Wed, May 25, 2016 at 08:33:45AM +0800, Qu Wenruo wrote:
David Sterba wrote on 2016/05/24 11:51 +0200:
On Tue, May 24, 2016 at 08:31:01AM +0800, Qu Wenruo wrote:
This could be made static (with thread local storage) so the state
does
not get regenerated all the time. Possibly it could be initialize
from
some true random source, not time or pid.
I also considered true random source like /dev/random, but since it's
possible to wait for entropy pool, it would be quite slow and
confusing
for users.
How would it be confusing? We'll once seed the random generator from
/dev/random, reading 3 * 16bit for the nrand generator context.
Reading from /dev/random may sleep, until the entropy pool is filled.
I know, but does this apply in our case? We're going to get just a few
bytes to seed. I want to avoid inventing own random number generation
schemes, so we'll use a standard random number source or API.
/dev/random gives about 1-2MB/s of random data on several machines I've
tried.
You have a lot of systems with a lot of spare entropy then, or you
unintentionally added a 'u' at the beginning of 'random' and were only
testing on slow systems. Some people (myself included) do seed
/dev/random from hardware RNG's or other daemons (I run both HAVEGE and
rngd), but many people don't, and a majority of embedded systems I've
seen absolutely don't. 48-bits may not seem like much, but if we're
using /dev/random, it has the potential to block indefinitely, and
having that possibility in end-user software is not a good thing.
I would tend to agree with Hugo on this one, we should be using
/dev/urandom, not /dev/random.
Completely agree on using uramdom.
For David, 1-2MB/s may be due to the long uptime of the system and other
hardware random number generator.
But for my personal and working PC, which get shutdown every day, its
entropy pool is so easy to be emptied that I have to use rngd to
manually fill the entropy pool.
That's the reason I try my best to avoid /dev/random use.
I just forgot we could use urandom, which is as good as random for
non-crypto usage.
I'll update it soon.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
