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: <1CB9B4D1-1E32-42DC-A4E9-6E53C85365BF@amacapital.net> Date: Thu, 3 Dec 2020 09:42:54 -0800 From: Andy Lutomirski <luto@...capital.net> To: Florian Weimer <fweimer@...hat.com> Cc: Topi Miettinen <toiwoton@...il.com>, linux-hardening@...r.kernel.org, akpm@...ux-foundation.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Jann Horn <jannh@...gle.com>, Kees Cook <keescook@...omium.org>, Matthew Wilcox <willy@...radead.org>, Mike Rapoport <rppt@...nel.org>, Linux API <linux-api@...r.kernel.org> Subject: Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack > On Dec 3, 2020, at 9:29 AM, Florian Weimer <fweimer@...hat.com> wrote: > > * Andy Lutomirski: > >> If you want a 4GB allocation to succeed, you can only divide the >> address space into 32k fragments. Or, a little more precisely, if you >> want a randomly selected 4GB region to be empty, any other allocation >> has a 1/32k chance of being in the way. (Rough numbers — I’m ignoring >> effects of the beginning and end of the address space, and I’m >> ignoring the size of a potential conflicting allocation.). > > I think the probability distribution is way more advantageous than that > because it is unlikely that 32K allocations are all exactly spaced 4 GB > apart. (And with 32K allocations, you are close to the VMA limit anyway.) I’m assuming the naive algorithm of choosing an address and trying it. Actually looking for a big enough gap would be more reliable. I suspect that something much more clever could be done in which the heap is divided up into a few independently randomized sections and heap pages are randomized within the sections might do much better. There should certainly be a lot of room for something between what we have now and a fully randomized scheme. It might also be worth looking at what other OSes do.
Powered by blists - more mailing lists