[lkml]   [2002]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Continuing /dev/random problems with 2.4
    On Feb 01, 2002  13:38 -0600, Ken Brownfield wrote:
    > Of course, in my case deleting the /dev/random character node still
    > doesn't allow entropy to drain in (after at least a month) so I suspect
    > the kernel's entropy generation would be sufficient if it didn't
    > artificially stall or drain from within the kernel.

    Hmm, you may also need to delete /dev/urandom too. Reading from
    /dev/urandom will also deplete the entropy pool just as much as
    reading from /dev/random. The only difference is that /dev/random
    will block if there aren't enough bits as requested, while reads
    from /dev/urandom will happily continue to return data which isn't
    "backed" by any entropy.

    You could also enable debugging in drivers/char/random.c to see what
    is going on (it may be very verbose). You could even change the one
    message in extract_entropy() to include the command name, like:

    DEBUG_ENT("%s has %d bits, %s wants %d bits\n",
    r == sec_random_state ? "secondary" :
    r == random_state ? "primary" : "unknown",
    current->comm, r->entropy_bits, nbytes * 8);

    (not sure of exact usage for current->comm, but you could use ->pid

    Note that even traffic over the network will deplete your entropy
    pool, because it is using secure_tcp_sequence_number() and secure_ip_id().
    Also, using SYN cookies appears to increase the amount of entropy used.

    Cheers, Andreas
    Andreas Dilger

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:23    [W:0.022 / U:37.096 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site