Re: Kernel hardening project suggestion: Normalizing ->ctor slabs and TYPESAFE_BY_RCU slabs

[Marco Elver <elver@google.com>]

On Tue, 23 Jun 2020 at 08:45, Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Jun 23, 2020 at 8:26 AM Jann Horn <jannh@google.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 [1], that's KASAN laundry list.
>
> +Alex, Marco, will it be useful for KFENCE [2] 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.

> [1] https://bugzilla.kernel.org/buglist.cgi?bug_status=__open__&component=Sanitizers&list_id=1063981&product=Memory%20Management
> [2] https://github.com/google/kasan/commits/kfence