-----BEGIN PGP SIGNED MESSAGE----- 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.... [ ]|STACK---STACK---NONONOSHELLCODE STACK---STACK---NONONOSHELLCODE - ----------------------^ | - -- 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+ScghDd4aOud5P8RAk3zAJ9u3eav0l/Uhd3tQJ7uhDch+bepmACfeuYT bQH8NCKkDXpmOPsXjVZ9cw4= =e6OC -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
