| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20071025071324.2eac21d6@laptopd505.fenrus.org> Date: Thu, 25 Oct 2007 07:13:24 -0700 From: Arjan van de Ven <arjan@...radead.org> To: Sami Farin <safari-kernel@...ari.iki.fi> Cc: Linux kernel Mailing List <linux-kernel@...r.kernel.org>, Jiri Kosina <jkosina@...e.cz> Subject: Re: x86: randomize brk() and RLIMIT_DATA On Thu, 25 Oct 2007 16:41:24 +0300 Sami Farin <safari-kernel@...ari.iki.fi> wrote: > Would be neat if randomized brk and setrlimit(RLIMIT_DATA, ...) > worked in a predictable way: this isn't a valid case afaics; even on "traditional x86" (before we changed the address space layout, or even today if you have an unlimited stack rlimit) this isn't going to work. applications really shouldn't use (s)brk() but malloc(); you have to be able to fall back to mmap regardless of what you do. > > $ gcc brk.c -fPIC -pie -m64;./a.out;./a.out;./a.out > sbrk=0x7f721b815000 main=0x7f721af04860 > sbrk succeeded (brk=0x7f721b909240) > sbrk=0x7fc3d77e2000 main=0x7fc3d66fa860 > sbrk failed: Cannot allocate memory (brk=0x7fc3d77e2000) > sbrk=0x7f05b0615000 main=0x7f05af76b860 > sbrk failed: Cannot allocate memory (brk=0x7f05b0615000) > -- If you want to reach me at my work email, use arjan@...ux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists