linux-kernel - Re: [PATCH v8 2/2] slub: Introduce CONFIG_SLUB_RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vltpi3jesch5tgwutyot7xkggkl3pyem7eqbzobx4ptqkiyr47@vpbo2bgdtldm>
Date: Tue, 13 Aug 2024 09:03:03 +0000
From: Shinichiro Kawasaki <shinichiro.kawasaki@....com>
To: Jann Horn <jannh@...gle.com>
CC: Andrey Ryabinin <ryabinin.a.a@...il.com>, Alexander Potapenko
	<glider@...gle.com>, Andrey Konovalov <andreyknvl@...il.com>, Dmitry Vyukov
	<dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, Andrew
 Morton <akpm@...ux-foundation.org>, Christoph Lameter <cl@...ux.com>, Pekka
 Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo
 Kim <iamjoonsoo.kim@....com>, Vlastimil Babka <vbabka@...e.cz>, Roman
 Gushchin <roman.gushchin@...ux.dev>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
	Marco Elver <elver@...gle.com>, "kasan-dev@...glegroups.com"
	<kasan-dev@...glegroups.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	David Sterba <dsterba@...e.cz>,
	"syzbot+263726e59eab6b442723@...kaller.appspotmail.com"
	<syzbot+263726e59eab6b442723@...kaller.appspotmail.com>
Subject: Re: [PATCH v8 2/2] slub: Introduce CONFIG_SLUB_RCU_DEBUG

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?