From: Florian Weimer <fweimer@redhat.com>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-hardening@vger.kernel.org, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack
Date: Thu, 03 Dec 2020 10:47:51 +0100 [thread overview]
Message-ID: <87im9j2pbs.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20201129211517.2208-1-toiwoton@gmail.com> (Topi Miettinen's message of "Sun, 29 Nov 2020 23:15:17 +0200")
* Topi Miettinen:
> +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 and the location of stack and vdso are also
> + randomized.
> +
> + On 32 bit systems this may cause problems due to increased VM
> + fragmentation if the address space gets crowded.
Isn't this a bit of an understatement? I think you'll have to restrict
this randomization to a subregion of the entire address space, otherwise
the reduction in maximum mapping size due to fragmentation will be a
problem on 64-bit architectures as well (which generally do not support
the full 64 bits for user-space addresses).
> + 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. In the worst case,
> + additional page table entries of up to 4 pages are created for
> + each mapping, so with small mappings there's considerable penalty.
The number 4 is architecture-specific, right?
Thanks,
Florian
--
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
next prev parent reply other threads:[~2020-12-03 9:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-29 21:15 [PATCH v5] mm: Optional full ASLR for mmap(), mremap(), vdso and stack Topi Miettinen
2020-11-30 6:08 ` kernel test robot
2020-11-30 6:08 ` kernel test robot
2020-11-30 17:57 ` Andy Lutomirski
2020-11-30 20:27 ` Topi Miettinen
2020-12-03 9:47 ` Florian Weimer [this message]
2020-12-03 12:02 ` Topi Miettinen
2020-12-03 17:10 ` Andy Lutomirski
2020-12-03 17:28 ` Florian Weimer
2020-12-03 17:42 ` Andy Lutomirski
2020-12-03 18:00 ` Matthew Wilcox
2020-12-03 19:26 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87im9j2pbs.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=toiwoton@gmail.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.