Re: [PATCH v7 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Using KASAN to catch direct PTE accesses during per-CPU lazy MMU mode will cause false positive BUG reports on valid concurrent accesses from other CPUs.
--

--- Patch [3]: [PATCH v7 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer ---
commit 934c56df440d17dce73b955e4a04d2ffc114ef49
Author: Alexander Gordeev <agordeev@linux.ibm.com>

mm/kasan: Introduce helpers for lazy MMU mode sanitizer

This commit introduces helpers to allow architectures to use KASAN to catch
illegitimate direct PTE accesses while lazy MMU mode is enabled.

> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index b7d05c2a6d93d..94d1060949891 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c

[ ... ]

> @@ -163,6 +163,20 @@ void __kasan_poison_slab(struct slab *slab)
>  		     KASAN_SLAB_REDZONE, false);
>  }
>  
> +void __kasan_poison_pte(pte_t *pte, int nr)
> +{
> +	if (IS_ALIGNED(sizeof(*pte), KASAN_GRANULE_SIZE))
> +		kasan_poison(pte, sizeof(*pte) * nr, KASAN_LAZY_MMU_PTE, false);
> +}

[Severity: Medium]
If this helper poisons the PTE in the global KASAN shadow memory, will it
cause false positive KASAN splats for valid concurrent lockless readers?

For example, if another CPU performs a lockless page table walk like
GUP-fast and executes ptep_get(), the instrumented READ_ONCE(*ptep) would
trigger a lazy-mmu-pte-access report because the shadow memory was poisoned
by the per-CPU lazy MMU mode.

Does this API design conflict with shared page tables?

> +EXPORT_SYMBOL_GPL(__kasan_poison_pte);
> +
> +void __kasan_unpoison_pte(pte_t *pte, int nr)
> +{
> +	if (IS_ALIGNED(sizeof(*pte), KASAN_GRANULE_SIZE))
> +		kasan_unpoison(pte, sizeof(*pte) * nr, false);
> +}
> +EXPORT_SYMBOL_GPL(__kasan_unpoison_pte);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786956464.git.agordeev@linux.ibm.com?part=3