Date: Tue, 23 Jun 2020 09:17:54 +0200 From: Marco Elver <elver@...gle.com> To: Dmitry Vyukov <dvyukov@...gle.com> Cc: Jann Horn <jannh@...gle.com>, Kernel Hardening <kernel-hardening@...ts.openwall.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>, Linux-MM <linux-mm@...ck.org>, Andrey Konovalov <andreyknvl@...gle.com>, Will Deacon <will@...nel.org>, kasan-dev <kasan-dev@...glegroups.com>, Kees Cook <keescook@...gle.com>, Alexander Potapenko <glider@...gle.com> Subject: Re: Kernel hardening project suggestion: Normalizing ->ctor slabs and TYPESAFE_BY_RCU slabs On Tue, 23 Jun 2020 at 08:45, Dmitry Vyukov <dvyukov@...gle.com> wrote: > > On Tue, Jun 23, 2020 at 8:26 AM Jann Horn <jannh@...gle.com> wrote: > > > > Hi! > > > > 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. > > - 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. > > Hi Jann, > > Both things sound good to me. I think we considered doing the ctor's > change with KASAN, but we did not get anywhere. The only argument > against it I remember now was "performance", but it's not that > important if this mode is enabled only with KASAN and other debugging > tools. Performance is definitely not as important as missing bugs. The > additional code complexity for ctors change should be minimal. > The rcu change would also be useful, but I would assume it will be larger. > Please add them to , that's KASAN laundry list. > > +Alex, Marco, will it be useful for KFENCE  as well? Do ctors/rcu > affect KFENCE? Will we need any special handling for KFENCE? > I assume it will also be useful for KMSAN b/c we can re-mark objects > as uninitialized only after they have been reallocated. Yes, we definitely need to handle TYPESAFE_BY_RCU. >  https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&component=Sanitizers&list_id=1063981&product=Memory%20Management >  https://github.com/google/kasan/commits/kfence
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.