On Mon, Oct 06, 2008 at 09:26:41PM +0200, Andi Kleen wrote:
quoted text
> > We're already using get_random* for stack, heap, and brk.  Also,
> > get_random* uses the nonblocking pool, so this is the same as if userspace
> > had tried to pull bytes out of /dev/urandom, which (as I understand it)
> 
> Yes exactly that's the problem. Think about it: do you really 
> need the same cryptographic strength for your mmap placement
> as you need for your SSL session keys?

Well, my ultimate intention was to put this into the stack protector
guard value, so I did want something as strong as the ASLR.

quoted text
> 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.)

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
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.  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?

-Kees

-- 
Kees Cook
Ubuntu Security Team
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/