[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d08abd1-4343-59e7-108a-68af5f7778c0@gmail.com>
Date: Thu, 8 Oct 2020 21:11:22 +0300
From: Topi Miettinen <toiwoton@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-hardening@...r.kernel.org, akpm@...ux-foundation.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v2] mm: Optional full ASLR for mmap() and mremap()
On 8.10.2020 20.07, Matthew Wilcox wrote:
> On Thu, Oct 08, 2020 at 07:54:08PM +0300, Topi Miettinen wrote:
>> +3 Additionally enable full randomization of memory mappings created
>> + with mmap(NULL, ...). With 2, the base of the VMA used for such
>> + mappings is random, but the mappings are created in predictable
>> + places within the VMA and in sequential order. With 3, new VMAs
>> + are created to fully randomize the mappings. Also mremap(...,
>> + MREMAP_MAYMOVE) will move the mappings even if not necessary.
>> +
>> + On 32 bit systems this may cause problems due to increased VM
>> + fragmentation if the address space gets crowded.
>
> On all systems, it will reduce performance and increase memory usage due
> to less efficient use of page tables and inability to merge adjacent VMAs
> with compatible attributes.
Right, I'll update the description.
>> + if ((flags & MREMAP_MAYMOVE) && randomize_va_space >= 3) {
>> + /*
>> + * Caller is happy with a different address, so let's
>> + * move even if not necessary!
>> + */
>> + new_addr = arch_mmap_rnd();
>> +
>> + ret = mremap_to(addr, old_len, new_addr, new_len,
>> + &locked, flags, &uf, &uf_unmap_early,
>> + &uf_unmap);
>> + goto out;
>> + }
>> +
>> +
>
> Overly enthusiastic newline
>
Will remove.
-Topi
Powered by blists - more mailing lists