[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG_fn=UfKBSxgcNp5dB3DDoNAnCpDbYoV8HC4BhS7LbgQSpwQw@mail.gmail.com>
Date: Fri, 5 Sep 2025 10:32:46 +0200
From: Alexander Potapenko <glider@...gle.com>
To: Ethan Graham <ethan.w.s.graham@...il.com>
Cc: ethangraham@...gle.com, andreyknvl@...il.com, brendan.higgins@...ux.dev,
davidgow@...gle.com, dvyukov@...gle.com, jannh@...gle.com, elver@...gle.com,
rmoar@...gle.com, shuah@...nel.org, tarasmadan@...gle.com,
kasan-dev@...glegroups.com, kunit-dev@...glegroups.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org, dhowells@...hat.com,
lukas@...ner.de, ignat@...udflare.com, herbert@...dor.apana.org.au,
davem@...emloft.net, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2 RFC 1/7] mm/kasan: implement kasan_poison_range
On Mon, Sep 1, 2025 at 6:43 PM Ethan Graham <ethan.w.s.graham@...il.com> wrote:
>
> From: Ethan Graham <ethangraham@...gle.com>
>
> Introduce a new helper function, kasan_poison_range(), to encapsulate
> the logic for poisoning an arbitrary memory range of a given size, and
> expose it publically in <include/linux/kasan.h>.
>
> This is a preparatory change for the upcoming KFuzzTest patches, which
> requires the ability to poison the inter-region padding in its input
> buffers.
>
> No functional change to any other subsystem is intended by this commit.
>
> Signed-off-by: Ethan Graham <ethangraham@...gle.com>
> ---
> include/linux/kasan.h | 16 ++++++++++++++++
> mm/kasan/shadow.c | 31 +++++++++++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 890011071f2b..09baeb6c9f4d 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -102,6 +102,21 @@ static inline bool kasan_has_integrated_init(void)
> }
>
> #ifdef CONFIG_KASAN
> +
> +/**
> + * kasan_poison_range - poison the memory range [start, start + size)
> + *
> + * The exact behavior is subject to alignment with KASAN_GRANULE_SIZE, defined
> + * in <mm/kasan/kasan.h>.
> + *
> + * - If @start is unaligned, the initial partial granule at the beginning
> + * of the range is only poisoned if CONFIG_KASAN_GENERIC is enabled.
Nit: for consistency with other functions in this header, can we
change @start to @addr?
> + * - The poisoning of the range only extends up to the last full granule before
> + * the end of the range. Any remaining bytes in a final partial granule are
> + * ignored.
Maybe we should require that the end of the range is aligned, as we do
for e.g. kasan_unpoison()?
Are there cases in which we want to call it for non-aligned addresses?
>
> +void kasan_poison_range(const void *start, size_t size)
> +{
> + void *end = (char *)start + size;
There's only a single use of `end` below, so maybe drop this variable
altogether?
> + uintptr_t start_addr = (uintptr_t)start;
> + uintptr_t head_granule_start;
> + uintptr_t poison_body_start;
> + uintptr_t poison_body_end;
> + size_t head_prefix_size;
> + uintptr_t end_addr;
> +
> + end_addr = ALIGN_DOWN((uintptr_t)end, KASAN_GRANULE_SIZE);
I suggest making it
end_addr = ALIGN_DOWN((uintptr_t)start + size, KASAN_GRANULE_SIZE);
instead.
Powered by blists - more mailing lists