lkml.org 
[lkml]   [2008]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] ELF: implement AT_RANDOM for future glibc use
    On Mon, Oct 06, 2008 at 03:01:01PM -0700, Kees Cook wrote:
    > > Since so many systems have poor entropy input /dev/urandom has generally
    > > replaced /dev/random for near all cryptographic software, so it's
    > > just the new black.
    >
    > If I understand, you're suggesting that ASLR doesn't need to be strong,
    > and that there should be something besides get_random* used to produce
    > these values? If that's true, that has nothing to do with the patch
    > I've suggested (i.e. we have an immediate need and I'm solving it using
    > the current available solutions.) (Additionally, I think ASLR should be
    > as strong as possible.)

    Sure in a perfect world we had endless money and endless entropy
    and no world hunger and could make all such RNGs truly random.

    But in practice the world is not like that. And entropy on a standard
    Linux system is a very precious commodity.

    And you won't deny that session keys are more important than mmap
    placement, will you?

    >
    > If instead, you're saying that the use of urandom has generally caused
    > a drain on entropy, and ASLR is suffering, then does it matter that a
    > few more bytes are used for the stack guard? I'm just not clear what

    It's eating entropy on every process start, so it's a incredible
    drain on the entropy pool. Just calculate how much entropy
    a standard "configure" run or kernel build will need.

    > direction you're trying to aim my patch. :)
    >
    > I'd really love to see this solved. My goal is to get a mainline glibc
    > patch for a low-cost randomized stack guard value.

    Your current implementation is high cost.

    > Ulrich has a set of
    > requirements, and it sounds like there's a growing new set of requirements
    > from the kernel folks. What's needed to sort this out?

    IMHO it needs a new class of random numbers in the kernel that use
    some cryptographically strong RNG (there are a couple of candidates
    like yarrow) which is very rarely seeded
    from the entropy pool[1] and use that for these applications.
    A couple of other users in the kernel would benefit that too,
    most users of get_random_bytes() probably should be reviewed
    for their true requirements.
    Ideally expose it to userland too so that dumb users like
    tmpfile can use it too.

    An alternative would be also to use existing entropy sources
    like the TPMs which are in many boxes now better and automatically,
    but that doesn't help on systems without TPM.

    -Andi

    [1] getting that right is tricky, note that the entropy pool
    is useless early at boot because there's no random input.

    --
    ak@linux.intel.com


    \
     
     \ /
      Last update: 2008-10-07 01:15    [W:2.107 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site