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: randomized stack protector value


On Wed, Oct 01, 2008 at 03:27:06PM -0700, Roland McGrath wrote:
> > The right solution is that the kernel provides a couple of random words
> > in the auxiliary vectors.  Some kernel folks know about this for quite some
> > time, but it hasn't been added yet.  If kernel provides it, upstream
> > glibc will most definitely use it.
> 
> Sounds easy enough.  How many?  Do you want:
> 
> 	{AT_RANDOM1, x}
> 	{AT_RANDOM2, y}
> 
> giving 8 bytes on 32-bit and 16 on 64-bit?
> 
> Or perhaps:
> 
> 	{AT_RANDOM, a}
> 	{AT_RANDOM_SIZE, p}
> 
> where a is the address (on the initial stack near auxv) of p random bytes?

I think the latter is much more extensible and uses fewer AT_ values.
The prior style was the direction of the earlier discussion[1].
Eventually, it went a different direction[2], but I think the values
should grow according to address size as you mentioned.  It seems
like get_random_long() should just be arch-defined into one or two
get_random_int() calls, depending on the need of the architecture,
or am I missing some critical PRNG theory?

> Then what should p be in the initial implementation?

We'd immediately use 1 for the stack protector.  How is libc internal
ptr obfuscation handled?  I haven't looked at that code yet.  I can
easily imagine using a third for malloc agitation.  How about 4?

(And how does a consumer of these values mark them as having been used?
Reduce the AT_RANDOM_SIZE value?  Should AT_RANDOM_SIZE be defined as
bytes, so that partial values can be used?  e.g. the stack protector
would use 3 bytes per int to retain a static NULL byte.)

I've been assuming the "expense" of reading /dev/urandom is due to the VFS
overhead in open/read/close on every exec.  If the expense is actually
the extraction of random bits, then I don't think Linus's question[3]
should go unanswered.  Is this going to cause any kind of measurable
performance loss?  (I have been assuming "no".)

-Kees

[1] http://sourceware.org/ml/libc-alpha/2007-06/msg00088.html
[2] http://sourceware.org/ml/libc-alpha/2007-06/msg00100.html
[3] http://sourceware.org/ml/libc-alpha/2007-06/msg00102.html

-- 
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]