All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, andreyknvl@gmail.com,
	dvyukov@google.com, glider@google.com, pcc@google.com,
	ryabinin.a.a@gmail.com, vincenzo.frascino@arm.com,
	will@kernel.org
Subject: Re: [PATCH 2/3] arm64: kasan: mte: use a constant kernel GCR_EL1 value
Date: Tue, 27 Jul 2021 19:29:19 +0100	[thread overview]
Message-ID: <20210727182919.GT13920@arm.com> (raw)
In-Reply-To: <20210714143843.56537-3-mark.rutland@arm.com>

On Wed, Jul 14, 2021 at 03:38:42PM +0100, Mark Rutland wrote:
> When KASAN_HW_TAGS is selected, KASAN is enabled at boot time, and the
> hardware supports MTE, we'll initialize `kernel_gcr_excl` with a value
> dependent on KASAN_TAG_MAX. While the resulting value is a constant
> which depends on KASAN_TAG_MAX, we have to perform some runtime work to
> generate the value, and have to read the value from memory during the
> exception entry path. It would be better if we could generate this as a
> constant at compile-time, and use it as such directly.
> 
> Early in boot within __cpu_setup(), we initialize GCR_EL1 to a safe
> value, and later override this with the value required by KASAN. If
> CONFIG_KASAN_HW_TAGS is not selected, or if KASAN is disabeld at boot
> time, the kernel will not use IRG instructions, and so the initial value
> of GCR_EL1 is does not matter to the kernel. Thus, we can instead have
> __cpu_setup() initialize GCR_EL1 to a value consistent with
> KASAN_TAG_MAX, and avoid the need to re-initialize it during hotplug and
> resume form suspend.
> 
> This patch makes arem64 use a compile-time constant KERNEL_GCR_EL1
> value, which is compatible with KASAN_HW_TAGS when this is selected.
> This removes the need to re-initialize GCR_EL1 dynamically, and acts as
> an optimization to the entry assembly, which no longer needs to load
> this value from memory. The redundant initialization hooks are removed.
> 
> In order to do this, KASAN_TAG_MAX needs to be visible outside of the
> core KASAN code. To do this, I've moved the KASAN_TAG_* values into
> <linux/kasan-tags.h>.
> 
> There should be no functional change as a result of this patch.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> Cc: Peter Collingbourne <pcc@google.com>
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Cc: Will Deacon <will@kernel.org>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

> diff --git a/include/linux/kasan-tags.h b/include/linux/kasan-tags.h
> new file mode 100644
> index 000000000000..4f85f562512c
> --- /dev/null
> +++ b/include/linux/kasan-tags.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_KASAN_TAGS_H
> +#define _LINUX_KASAN_TAGS_H
> +
> +#define KASAN_TAG_KERNEL	0xFF /* native kernel pointers tag */
> +#define KASAN_TAG_INVALID	0xFE /* inaccessible memory tag */
> +#define KASAN_TAG_MAX		0xFD /* maximum value for random tags */
> +
> +#ifdef CONFIG_KASAN_HW_TAGS
> +#define KASAN_TAG_MIN		0xF0 /* minimum value for random tags */
> +#else
> +#define KASAN_TAG_MIN		0x00 /* minimum value for random tags */
> +#endif
> +
> +#endif /* LINUX_KASAN_TAGS_H */

If the kasan folk are happy with this change, I can take the patches
through the arm64 tree.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-27 18:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-14 14:38 [PATCH 0/3] arm64: MTE cleanups Mark Rutland
2021-07-14 14:38 ` [PATCH 1/3] arm64: mte: fix restoration of GCR_EL1 from suspend Mark Rutland
2021-07-14 14:38 ` [PATCH 2/3] arm64: kasan: mte: use a constant kernel GCR_EL1 value Mark Rutland
2021-07-27 18:29   ` Catalin Marinas [this message]
2021-08-02 11:57   ` Andrey Konovalov
2021-07-14 14:38 ` [PATCH 3/3] arm64: kasan: mte: remove redundant mte_report_once logic Mark Rutland
2021-07-27 18:54   ` Catalin Marinas
2021-07-30 23:01     ` Andrey Konovalov
2021-07-31 10:44       ` Catalin Marinas
2021-07-31 11:28         ` Andrey Konovalov
2021-07-31 11:49           ` Catalin Marinas
2021-08-02 11:52             ` Andrey Konovalov
2021-07-15 17:39 ` [PATCH 0/3] arm64: MTE cleanups Will Deacon
2021-08-02 18:07 ` (subset) " Catalin Marinas

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=20210727182919.GT13920@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=andreyknvl@gmail.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=pcc@google.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.