Re: [PATCH] kasan: guard release_free_meta() shadow access with kasan_arch_is_ready()

[Andrey Konovalov <andreyknvl@gmail.com>]

On Tue, Feb 13, 2024 at 4:40 AM Benjamin Gray <bgray@linux.ibm.com> wrote:
>
> release_free_meta() accesses the shadow directly through the path
>
>   kasan_slab_free
>     __kasan_slab_free
>       kasan_release_object_meta
>         release_free_meta
>           kasan_mem_to_shadow
>
> There are no kasan_arch_is_ready() guards here, allowing an oops when
> the shadow is not initialized. The oops can be seen on a Power8 KVM
> guest.
>
> This patch adds the guard to release_free_meta(), as it's the first
> level that specifically requires the shadow.
>
> It is safe to put the guard at the start of this function, before the
> stack put: only kasan_save_free_info() can initialize the saved stack,
> which itself is guarded with kasan_arch_is_ready() by its caller
> poison_slab_object(). If the arch becomes ready before
> release_free_meta() then we will not observe KASAN_SLAB_FREE_META in the
> object's shadow, so we will not put an uninitialized stack either.
>
> Signed-off-by: Benjamin Gray <bgray@linux.ibm.com>
>
> ---
>
> I am interested in removing the need for kasan_arch_is_ready() entirely,
> as it mostly acts like a separate check of kasan_enabled().

Dropping kasan_arch_is_ready() calls from KASAN internals and instead
relying on kasan_enabled() checks in include/linux/kasan.h would be
great!

I filed a bug about this a while ago:
https://bugzilla.kernel.org/show_bug.cgi?id=217049

> Currently
> both are necessary, but I think adding a kasan_enabled() guard to
> check_region_inline() makes kasan_enabled() a superset of
> kasan_arch_is_ready().

Sounds good to me. I would also go through the list of other exported
KASAN functions to check whether any of them also need a
kasan_enabled() check. At least kasan_unpoison_task_stack() seems to
be one of them.

> Allowing an arch to override kasan_enabled() can then let us replace it
> with a static branch that we enable somewhere in boot (for PowerPC,
> after we use a bunch of generic code to parse the device tree to
> determine how we want to configure the MMU). This should generally work
> OK I think, as HW tags already does this,

We can also add something like CONFIG_ARCH_HAS_KASAN_FLAG_ENABLE and
only use a static branch only on those architectures where it's
required.

> but I did have to add another
> patch for an uninitialised data access it introduces.

What was this data access? Is this something we need to fix in the mainline?

> On the other hand, KASAN does more than shadow based sanitisation, so
> we'd be disabling that in early boot too.

I think the things that we need to handle before KASAN is enabled is
kasan_cache_create() and kasan_metadata_size() (if these can even
called before KASAN is enabled). Otherwise, KASAN just collects
metadata, which is useless without shadow memory-based reporting
anyway.

> ---
>  mm/kasan/generic.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index df6627f62402..032bf3e98c24 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -522,6 +522,9 @@ static void release_alloc_meta(struct kasan_alloc_meta *meta)
>
>  static void release_free_meta(const void *object, struct kasan_free_meta *meta)
>  {
> +       if (!kasan_arch_is_ready())
> +               return;
> +
>         /* Check if free meta is valid. */
>         if (*(u8 *)kasan_mem_to_shadow(object) != KASAN_SLAB_FREE_META)
>                 return;
> --
> 2.43.0
>

For the patch itself as a fix:

Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>

Thanks!