From: Will Deacon <will@kernel.org>
To: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com,
dvyukov@google.com, vincenzo.frascino@arm.com, corbet@lwn.net,
catalin.marinas@arm.com, akpm@linux-foundation.org,
scott@os.amperecomputing.com, jhubbard@nvidia.com,
pankaj.gupta@amd.com, leitao@debian.org, kaleshsingh@google.com,
maz@kernel.org, broonie@kernel.org, oliver.upton@linux.dev,
james.morse@arm.com, ardb@kernel.org,
hardevsinh.palaniya@siliconsignals.io, david@redhat.com,
yang@os.amperecomputing.com, kasan-dev@googlegroups.com,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Subject: Re: [PATCH v7 1/2] kasan/hw-tags: introduce kasan.write_only option
Date: Tue, 16 Sep 2025 20:31:00 +0100 [thread overview]
Message-ID: <aMm69C3IGuDHF248@willie-the-truck> (raw)
In-Reply-To: <20250903150020.1131840-2-yeoreum.yun@arm.com>
On Wed, Sep 03, 2025 at 04:00:19PM +0100, Yeoreum Yun wrote:
> Since Armv8.9, FEATURE_MTE_STORE_ONLY feature is introduced to restrict
> raise of tag check fault on store operation only.
> Introcude KASAN write only mode based on this feature.
Typo ^^
>
> KASAN write only mode restricts KASAN checks operation for write only and
> omits the checks for fetch/read operations when accessing memory.
> So it might be used not only debugging enviroment but also normal
> enviroment to check memory safty.
>
> This features can be controlled with "kasan.write_only" arguments.
> When "kasan.write_only=on", KASAN checks write operation only otherwise
> KASAN checks all operations.
>
> This changes the MTE_STORE_ONLY feature as BOOT_CPU_FEATURE like
> ARM64_MTE_ASYMM so that makes it initialise in kasan_init_hw_tags()
> with other function together.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> Documentation/dev-tools/kasan.rst | 3 ++
> arch/arm64/include/asm/memory.h | 1 +
> arch/arm64/include/asm/mte-kasan.h | 6 +++
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/mte.c | 18 ++++++++
> mm/kasan/hw_tags.c | 70 +++++++++++++++++++++++++++++-
> mm/kasan/kasan.h | 7 +++
> 7 files changed, 104 insertions(+), 3 deletions(-)
[...]
> diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
> index 9a6927394b54..d5b5fb47d52b 100644
> --- a/mm/kasan/hw_tags.c
> +++ b/mm/kasan/hw_tags.c
> @@ -41,9 +41,16 @@ enum kasan_arg_vmalloc {
> KASAN_ARG_VMALLOC_ON,
> };
>
> +enum kasan_arg_write_only {
> + KASAN_ARG_WRITE_ONLY_DEFAULT,
> + KASAN_ARG_WRITE_ONLY_OFF,
> + KASAN_ARG_WRITE_ONLY_ON,
> +};
> +
> static enum kasan_arg kasan_arg __ro_after_init;
> static enum kasan_arg_mode kasan_arg_mode __ro_after_init;
> static enum kasan_arg_vmalloc kasan_arg_vmalloc __initdata;
> +static enum kasan_arg_write_only kasan_arg_write_only __ro_after_init;
>
> /*
> * Whether KASAN is enabled at all.
> @@ -67,6 +74,9 @@ DEFINE_STATIC_KEY_FALSE(kasan_flag_vmalloc);
> #endif
> EXPORT_SYMBOL_GPL(kasan_flag_vmalloc);
>
> +/* Whether to check write accesses only. */
> +static bool kasan_flag_write_only = false;
> +
> #define PAGE_ALLOC_SAMPLE_DEFAULT 1
> #define PAGE_ALLOC_SAMPLE_ORDER_DEFAULT 3
>
> @@ -141,6 +151,23 @@ static int __init early_kasan_flag_vmalloc(char *arg)
> }
> early_param("kasan.vmalloc", early_kasan_flag_vmalloc);
>
> +/* kasan.write_only=off/on */
> +static int __init early_kasan_flag_write_only(char *arg)
> +{
> + if (!arg)
> + return -EINVAL;
> +
> + if (!strcmp(arg, "off"))
> + kasan_arg_write_only = KASAN_ARG_WRITE_ONLY_OFF;
> + else if (!strcmp(arg, "on"))
> + kasan_arg_write_only = KASAN_ARG_WRITE_ONLY_ON;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +early_param("kasan.write_only", early_kasan_flag_write_only);
> +
> static inline const char *kasan_mode_info(void)
> {
> if (kasan_mode == KASAN_MODE_ASYNC)
> @@ -257,15 +284,28 @@ void __init kasan_init_hw_tags(void)
> break;
> }
>
> + switch (kasan_arg_write_only) {
> + case KASAN_ARG_WRITE_ONLY_DEFAULT:
> + /* Default is specified by kasan_flag_write_only definition. */
> + break;
> + case KASAN_ARG_WRITE_ONLY_OFF:
> + kasan_flag_write_only = false;
> + break;
> + case KASAN_ARG_WRITE_ONLY_ON:
> + kasan_flag_write_only = true;
> + break;
> + }
> +
> kasan_init_tags();
I'm probably missing something here, but why have 'enum
kasan_arg_write_only' at all? What stops you from setting
'kasan_flag_write_only' directly from early_kasan_flag_write_only()?
This all looks weirdly over-engineered, as though 'kasan_flag_write_only'
is expected to be statically initialised to something other than 'false'.
> /* KASAN is now initialized, enable it. */
> static_branch_enable(&kasan_flag_enabled);
>
> - pr_info("KernelAddressSanitizer initialized (hw-tags, mode=%s, vmalloc=%s, stacktrace=%s)\n",
> + pr_info("KernelAddressSanitizer initialized (hw-tags, mode=%s, vmalloc=%s, stacktrace=%s, write_only=%s)\n",
> kasan_mode_info(),
> str_on_off(kasan_vmalloc_enabled()),
> - str_on_off(kasan_stack_collection_enabled()));
> + str_on_off(kasan_stack_collection_enabled()),
> + str_on_off(kasan_arg_write_only));
It's also confusing, because now you appear to be passing the funny new
'enum' type to str_on_off(), which expects a bool.
Will
next prev parent reply other threads:[~2025-09-16 19:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 15:00 [PATCH v7 0/2] introduce kasan.write_only option in hw-tags Yeoreum Yun
2025-09-03 15:00 ` [PATCH v7 1/2] kasan/hw-tags: introduce kasan.write_only option Yeoreum Yun
2025-09-16 19:31 ` Will Deacon [this message]
2025-09-16 20:19 ` Yeoreum Yun
2025-09-16 21:23 ` Will Deacon
2025-09-16 21:47 ` Yeoreum Yun
2025-09-03 15:00 ` [PATCH v7 2/2] kasan: apply write-only mode in kasan kunit testcases Yeoreum Yun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMm69C3IGuDHF248@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=hardevsinh.palaniya@siliconsignals.io \
--cc=james.morse@arm.com \
--cc=jhubbard@nvidia.com \
--cc=kaleshsingh@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pankaj.gupta@amd.com \
--cc=ryabinin.a.a@gmail.com \
--cc=scott@os.amperecomputing.com \
--cc=vincenzo.frascino@arm.com \
--cc=workflows@vger.kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=yeoreum.yun@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox