[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 25 Aug 2023 23:22:03 +0200
From: Jann Horn <jannh@...gle.com>
To: Kernel Hardening <kernel-hardening@...ts.openwall.com>
Cc: 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>, Linux-MM <linux-mm@...ck.org>,
Andrey Konovalov <andreyknvl@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>,
Will Deacon <will@...nel.org>, kasan-dev <kasan-dev@...glegroups.com>,
Kees Cook <keescook@...gle.com>, Alexander Potapenko <glider@...gle.com>, Marco Elver <elver@...gle.com>
Subject: Re: Kernel hardening project suggestion: Normalizing ->ctor slabs and
TYPESAFE_BY_RCU slabs
On Tue, Jun 23, 2020 at 8:26 AM Jann Horn <jannh@...gle.com> wrote:
> Here's a project idea for the kernel-hardening folks:
>
> The slab allocator interface has two features that are problematic for
> security testing and/or hardening:
>
> - constructor slabs: These things come with an object constructor
> that doesn't run when an object is allocated, but instead when the
> slab allocator grabs a new page from the page allocator. This is
> problematic for use-after-free detection mechanisms such as HWASAN and
> Memory Tagging, which can only do their job properly if the address of
> an object is allowed to change every time the object is
> freed/reallocated. (You can't change the address of an object without
> reinitializing the entire object because e.g. an empty list_head
> points to itself.)
>
> - RCU slabs: These things basically permit use-after-frees by design,
> and stuff like ASAN/HWASAN/Memory Tagging essentially doesn't work on
> them.
>
>
> It would be nice to have a config flag or so that changes the SLUB
> allocator's behavior such that these slabs can be instrumented
> properly. Something like:
>
> - Let calculate_sizes() reserve space for an rcu_head on each object
> in TYPESAFE_BY_RCU slabs, make kmem_cache_free() redirect to
> call_rcu() for these slabs, and remove most of the other
> special-casing, so that KASAN can instrument these slabs.
I've implemented this first part now and sent it out for review:
https://lore.kernel.org/lkml/20230825211426.3798691-1-jannh@google.com/T/
> - For all constructor slabs, let slab_post_alloc_hook() call the
> ->ctor() function on each allocated object, so that Memory Tagging and
> HWASAN will work on them.
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.
