This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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