From: Andrew Morton <akpm@linux-foundation.org>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: linux-hardening@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Linux API <linux-api@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>, Vlad Rezki <urezki@gmail.com>
Subject: Re: [PATCH v3] mm/vmalloc: randomize vmalloc() allocations
Date: Fri, 5 Mar 2021 17:13:31 -0800 [thread overview]
Message-ID: <20210305171331.2424b166ed4d2d9da73ac335@linux-foundation.org> (raw)
In-Reply-To: <20210215202634.5121-1-toiwoton@gmail.com>
On Mon, 15 Feb 2021 22:26:34 +0200 Topi Miettinen <toiwoton@gmail.com> wrote:
> Memory mappings inside kernel allocated with vmalloc() are in
> predictable order and packed tightly toward the low addresses, except
> for per-cpu areas which start from top of the vmalloc area. With
> new kernel boot parameter 'randomize_vmalloc=1', the entire area is
> used randomly to make the allocations less predictable and harder to
> guess for attackers. Also module and BPF code locations get randomized
> (within their dedicated and rather small area though) and if
> CONFIG_VMAP_STACK is enabled, also kernel thread stack locations.
>
> 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 and
> cache usage due to less efficient use of page tables and inability to
> merge adjacent VMAs with compatible attributes. On x86_64 with 5 level
> page tables, 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.
>
> ...
>
How useful is this expected to be? What sort of attack scenarios will
this help to defend against?
And what do others think of the proposal?
next prev parent reply other threads:[~2021-03-06 1:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-15 20:26 [PATCH v3] mm/vmalloc: randomize vmalloc() allocations Topi Miettinen
2021-03-06 1:13 ` Andrew Morton [this message]
2021-03-06 5:57 ` Topi Miettinen
2021-03-08 21:38 ` Kees Cook
2021-03-09 13:49 ` Topi Miettinen
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=20210305171331.2424b166ed4d2d9da73ac335@linux-foundation.org \
--to=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=luto@kernel.org \
--cc=rppt@kernel.org \
--cc=toiwoton@gmail.com \
--cc=urezki@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).