From: David Hildenbrand <david@redhat.com>
To: Mark Brown <broonie@kernel.org>,
"Rick P. Edgecombe" <rick.p.edgecombe@intel.com>,
Deepak Gupta <debug@rivosinc.com>,
Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Christian Brauner <brauner@kernel.org>,
Shuah Khan <shuah@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Kees Cook <keescook@chromium.org>,
jannh@google.com, linux-kselftest@vger.kernel.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK
Date: Wed, 15 Nov 2023 16:12:50 +0100 [thread overview]
Message-ID: <ede57bf9-de69-48bc-9e09-b0ae3e37c8ab@redhat.com> (raw)
In-Reply-To: <20231114-clone3-shadow-stack-v2-1-b613f8681155@kernel.org>
On 14.11.23 21:05, Mark Brown wrote:
> Since multiple architectures have support for shadow stacks and we need to
> select support for this feature in several places in the generic code
> provide a generic config option that the architectures can select.
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/x86/Kconfig | 1 +
> fs/proc/task_mmu.c | 2 +-
> include/linux/mm.h | 2 +-
> mm/Kconfig | 6 ++++++
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3762f41bb092..14b7703a9a2b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1952,6 +1952,7 @@ config X86_USER_SHADOW_STACK
> depends on AS_WRUSS
> depends on X86_64
> select ARCH_USES_HIGH_VMA_FLAGS
> + select ARCH_HAS_USER_SHADOW_STACK
> select X86_CET
> help
> Shadow stack protection is a hardware feature that detects function
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index ef2eb12906da..f0a904aeee8e 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -699,7 +699,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> #ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
> [ilog2(VM_UFFD_MINOR)] = "ui",
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> -#ifdef CONFIG_X86_USER_SHADOW_STACK
> +#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> [ilog2(VM_SHADOW_STACK)] = "ss",
> #endif
> };
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 418d26608ece..10462f354614 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -341,7 +341,7 @@ extern unsigned int kobjsize(const void *objp);
> #endif
> #endif /* CONFIG_ARCH_HAS_PKEYS */
>
> -#ifdef CONFIG_X86_USER_SHADOW_STACK
> +#ifdef CONFIG_ARCH_HAS_USER_SHADOW_STACK
> /*
> * VM_SHADOW_STACK should not be set with VM_SHARED because of lack of
> * support core mm.
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 89971a894b60..b8638da636e1 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1270,6 +1270,12 @@ config LOCK_MM_AND_FIND_VMA
> bool
> depends on !STACK_GROWSUP
>
> +config ARCH_HAS_USER_SHADOW_STACK
> + bool
> + help
> + The architecture has hardware support for userspace shadow call
> + stacks (eg, x86 CET, arm64 GCS, RISC-V Zisslpcfi).
> +
Probably less controversial if we start with one example we have in
place: "e.g., x86 CET". That should be sufficient to understand what
this is about :)
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-11-15 15:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 20:05 [PATCH RFC RFT v2 0/5] fork: Support shadow stacks in clone3() Mark Brown
2023-11-14 20:05 ` [PATCH RFC RFT v2 1/5] mm: Introduce ARCH_HAS_USER_SHADOW_STACK Mark Brown
2023-11-14 23:22 ` Edgecombe, Rick P
2023-11-15 14:55 ` Mark Brown
2023-11-15 15:12 ` David Hildenbrand [this message]
2023-11-15 15:36 ` Deepak Gupta
2023-11-14 20:05 ` [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3() Mark Brown
2023-11-15 0:45 ` Edgecombe, Rick P
2023-11-15 12:36 ` Mark Brown
2023-11-15 16:20 ` Szabolcs.Nagy
2023-11-15 18:43 ` Mark Brown
2023-11-16 0:52 ` Edgecombe, Rick P
2023-11-16 10:32 ` Szabolcs.Nagy
2023-11-16 12:33 ` Mark Brown
2023-11-16 13:12 ` Szabolcs.Nagy
2023-11-16 13:55 ` Szabolcs.Nagy
2023-11-16 15:35 ` Mark Brown
2023-11-16 18:11 ` Edgecombe, Rick P
2023-11-16 18:41 ` Mark Brown
2023-11-17 17:43 ` Edgecombe, Rick P
2023-11-20 16:11 ` Mark Brown
2023-11-16 18:14 ` Mark Brown
2023-11-16 18:33 ` Edgecombe, Rick P
2023-11-17 20:51 ` Deepak Gupta
2023-11-14 20:05 ` [PATCH RFC RFT v2 3/5] selftests/clone3: Factor more of main loop into test_clone3() Mark Brown
2023-11-14 20:05 ` [PATCH RFC RFT v2 4/5] selftests/clone3: Allow tests to flag if -E2BIG is a valid error code Mark Brown
2023-11-14 20:05 ` [PATCH RFC RFT v2 5/5] kselftest/clone3: Test shadow stack support Mark Brown
2023-11-14 23:11 ` Edgecombe, Rick P
2023-11-15 12:53 ` Mark Brown
2023-11-17 18:16 ` Edgecombe, Rick P
2023-11-17 21:12 ` Deepak Gupta
2023-11-20 15:47 ` Mark Brown
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=ede57bf9-de69-48bc-9e09-b0ae3e37c8ab@redhat.com \
--to=david@redhat.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=bristot@redhat.com \
--cc=broonie@kernel.org \
--cc=bsegall@google.com \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=debug@rivosinc.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=juri.lelli@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=will@kernel.org \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).