From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jann Horn <jannh@google.com>,
Alexander Popov <alex.popov@linux.com>,
Will Deacon <will@kernel.org>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Patrick Bellasi <patrick.bellasi@arm.com>,
David Howells <dhowells@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Laura Abbott <labbott@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Daniel Micay <danielmicay@gmail.com>,
Andrey Konovalov <andreyknvl@google.com>,
Pavel Machek <pavel@denx.de>,
Valentin Schneider <valentin.schneider@arm.com>,
kasan-dev <kasan-dev@googlegroups.com>,
Linux-MM <linux-mm@kvack.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
kernel list <linux-kernel@vger.kernel.org>,
notify@kernel.org
Subject: Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free
Date: Mon, 5 Oct 2020 19:09:24 -0700 [thread overview]
Message-ID: <202010051905.62D79560@keescook> (raw)
In-Reply-To: <20201006004414.GP20115@casper.infradead.org>
On Tue, Oct 06, 2020 at 01:44:14AM +0100, Matthew Wilcox wrote:
> On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > It seems to me like, if you want to make UAF exploitation harder at
> > the heap allocator layer, you could do somewhat more effective things
> > with a probably much smaller performance budget. Things like
> > preventing the reallocation of virtual kernel addresses with different
> > types, such that an attacker can only replace a UAF object with
> > another object of the same type. (That is not an idea I like very much
> > either, but I would like it more than this proposal.) (E.g. some
> > browsers implement things along those lines, I believe.)
>
> The slab allocator already has that functionality. We call it
> TYPESAFE_BY_RCU, but if forcing that on by default would enhance security
> by a measurable amount, it wouldn't be a terribly hard sell ...
Isn't the "easy" version of this already controlled by slab_merge? (i.e.
do not share same-sized/flagged kmem_caches between different caches)
The large trouble are the kmalloc caches, which don't have types
associated with them. Having implicit kmem caches based on the type
being allocated there would need some pretty extensive plumbing, I
think?
--
Kees Cook
next prev parent reply other threads:[~2020-10-06 2:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 18:35 [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 1/6] mm: Extract SLAB_QUARANTINE from KASAN Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 2/6] mm/slab: Perform init_on_free earlier Alexander Popov
2020-09-30 12:50 ` Alexander Potapenko
2020-10-01 19:48 ` Alexander Popov
2020-12-03 19:50 ` Alexander Popov
2020-12-03 20:49 ` Andrew Morton
2020-12-04 11:54 ` Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 3/6] mm: Integrate SLAB_QUARANTINE with init_on_free Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 4/6] mm: Implement slab quarantine randomization Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 5/6] lkdtm: Add heap quarantine tests Alexander Popov
2020-09-29 18:35 ` [PATCH RFC v2 6/6] mm: Add heap quarantine verbose debugging (not for merge) Alexander Popov
2020-10-01 19:42 ` [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free Alexander Popov
2020-10-05 22:56 ` Jann Horn
2020-10-06 0:44 ` Matthew Wilcox
2020-10-06 0:48 ` Jann Horn
2020-10-06 2:09 ` Kees Cook [this message]
2020-10-06 2:16 ` Jann Horn
2020-10-06 2:19 ` Daniel Micay
2020-10-06 8:35 ` Christopher Lameter
2020-10-06 8:32 ` Christopher Lameter
2020-10-06 17:56 ` Alexander Popov
2020-10-06 18:37 ` Jann Horn
2020-10-06 19:25 ` Alexander Popov
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=202010051905.62D79560@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=alex.popov@linux.com \
--cc=andreyknvl@google.com \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=cl@linux.com \
--cc=danielmicay@gmail.com \
--cc=dhowells@redhat.com \
--cc=dvyukov@google.com \
--cc=ebiederm@xmission.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=krzk@kernel.org \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=notify@kernel.org \
--cc=patrick.bellasi@arm.com \
--cc=pavel@denx.de \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=valentin.schneider@arm.com \
--cc=will@kernel.org \
--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).