[lkml]   [2005]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Patch 4/6 randomize the stack pointer
Hash: SHA1

Arjan van de Ven wrote:
> The patch below replaces the existing 8Kb randomisation of the userspace
> stack pointer (which is currently only done for Hyperthreaded P-IVs) with a
> more general randomisation over a 64Kb range.

64k of stack randomization is trivial to evade. Know the alignment, and
stick branch instructions (or a stream of no-ops if they align)
periodically so that....

- ----------------------^
- -- You jump here in any case.

Now, in PaX, there's a randomization over something like a 256M range
for the stack IIRC. Who does a 256M stack overflow? It's several gigs
on 64 bit archs I think. I think it's 16 bits with 4k (12 bit) pages,
so.... 28 bits... 268435456.... 256M, yes. I'm pretty sure this is 24 +
12 on amd64 for example, so 64 gigs.

If your stack base is within 256M of ESP, you're safe. It's also fairly
implausible--definitely non-trivial--to do a 256M stack buffer overflow.
Programmatically it's no different; but in real life, that's 256M that
has to be in a corrupted jpeg, mp3 file, or network transmission.
Somebody's gonna notice. 64 gig doesn't happen.

Your patch 5/6 for mmap rand is also small. 1M is trivial, though I'd
imagine mmap() rand would pose a bit more confusion in some cases at
least, even for small ranges.

Still, this is a joke, like OpenBSD's stackgap.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [W:0.144 / U:0.356 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site