[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200815185455.GB17456@casper.infradead.org>
Date: Sat, 15 Aug 2020 19:54:55 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
Will Deacon <will@...nel.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Krzysztof Kozlowski <krzk@...nel.org>,
Patrick Bellasi <patrick.bellasi@....com>,
David Howells <dhowells@...hat.com>,
Eric Biederman <ebiederm@...ssion.com>,
Johannes Weiner <hannes@...xchg.org>,
Laura Abbott <labbott@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
kasan-dev@...glegroups.com, linux-mm@...ck.org,
kernel-hardening@...ts.openwall.com, linux-kernel@...r.kernel.org,
notify@...nel.org
Subject: Re: [PATCH RFC 1/2] mm: Extract SLAB_QUARANTINE from KASAN
On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote:
> +config SLAB_QUARANTINE
> + bool "Enable slab freelist quarantine"
> + depends on !KASAN && (SLAB || SLUB)
> + help
> + Enable slab freelist quarantine to break heap spraying technique
> + used for exploiting use-after-free vulnerabilities in the kernel
> + code. If this feature is enabled, freed allocations are stored
> + in the quarantine and can't be instantly reallocated and
> + overwritten by the exploit performing heap spraying.
> + This feature is a part of KASAN functionality.
After this patch, it isn't part of KASAN any more ;-)
The way this is written is a bit too low level. Let's write it in terms
that people who don't know the guts of the slab allocator or security
terminology can understand:
Delay reuse of freed slab objects. This makes some security
exploits harder to execute. It reduces performance slightly
as objects will be cache cold by the time they are reallocated,
and it costs a small amount of memory.
(feel free to edit this)
> +struct qlist_node {
> + struct qlist_node *next;
> +};
I appreciate this isn't new, but why do we have a new singly-linked-list
abstraction being defined in this code?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
