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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ