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

[Dmitry Vyukov <dvyukov@google.com>]

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.

[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