This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ELF: implement AT_RANDOM for future glibc use


On Mon, Oct 06, 2008 at 09:26:41PM +0200, Andi Kleen wrote:
> > 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.

> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]