Re: [PATCH v8 2/2] slub: Introduce CONFIG_SLUB_RCU_DEBUG

[Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

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?