Hello Jann, let me ask a question about this patch. When I tested the
next-20240808 kernel which includes this patch, I observed that
slab_free_after_rcu_debug() reports many WARNs. Please find my question in line.
On Aug 09, 2024 / 17:36, Jann Horn wrote:
> Currently, KASAN is unable to catch use-after-free in SLAB_TYPESAFE_BY_RCU
> slabs because use-after-free is allowed within the RCU grace period by
> design.
>
> Add a SLUB debugging feature which RCU-delays every individual
> kmem_cache_free() before either actually freeing the object or handing it
> off to KASAN, and change KASAN to poison freed objects as normal when this
> option is enabled.
>
> For now I've configured Kconfig.debug to default-enable this feature in the
> KASAN GENERIC and SW_TAGS modes; I'm not enabling it by default in HW_TAGS
> mode because I'm not sure if it might have unwanted performance degradation
> effects there.
>
> Note that this is mostly useful with KASAN in the quarantine-based GENERIC
> mode; SLAB_TYPESAFE_BY_RCU slabs are basically always also slabs with a
> ->ctor, and KASAN's assign_tag() currently has to assign fixed tags for
> those, reducing the effectiveness of SW_TAGS/HW_TAGS mode.
> (A possible future extension of this work would be to also let SLUB call
> the ->ctor() on every allocation instead of only when the slab page is
> allocated; then tag-based modes would be able to assign new tags on every
> reallocation.)
[...]
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index afc72fde0f03..41a58536531d 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -67,12 +67,44 @@ config SLUB_DEBUG_ON
> equivalent to specifying the "slab_debug" parameter on boot.
> There is no support for more fine grained debug control like
> possible with slab_debug=xxx. SLUB debugging may be switched
> off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
> "slab_debug=-".
>
> +config SLUB_RCU_DEBUG
> + bool "Enable UAF detection in TYPESAFE_BY_RCU caches (for KASAN)"
> + depends on SLUB_DEBUG
> + # SLUB_RCU_DEBUG should build fine without KASAN, but is currently useless
> + # without KASAN, so mark it as a dependency of KASAN for now.
> + depends on KASAN
> + default KASAN_GENERIC || KASAN_SW_TAGS
When I tested the next-20240808 kernel which includes this patch, I saw the
SLUB_RCU_DEBUG was enabled because I enable KASAN_GENERIC and KASAN_SW_TAGS
for my test target kernels. I also enable KFENCE.
[...]
> +#ifdef CONFIG_SLUB_RCU_DEBUG
> +static void slab_free_after_rcu_debug(struct rcu_head *rcu_head)
> +{
> + struct rcu_delayed_free *delayed_free =
> + container_of(rcu_head, struct rcu_delayed_free, head);
> + void *object = delayed_free->object;
> + struct slab *slab = virt_to_slab(object);
> + struct kmem_cache *s;
> +
> + kfree(delayed_free);
> +
> + if (WARN_ON(is_kfence_address(object)))
> + return;
With the kernel configs above, I see the many WARNs are reported here.
When SLUB_RCU_DEBUG is enabled, should I disable KFENCE?
