From: Deepak Gupta <debug@rivosinc.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Mark Brown <broonie@kernel.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Will Deacon <will@kernel.org>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Kito Cheng <kito.cheng@sifive.com>,
Jesse Huang <jesse.huang@sifive.com>,
valentin.haudiquet@canonical.com,
heinrich.schuchardt@canonical.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE
Date: Tue, 24 Feb 2026 16:06:13 -0800 [thread overview]
Message-ID: <aZ489QDHxEZfLydn@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20260224175800.2500729-1-catalin.marinas@arm.com>
+ Kito, Jesse, Valentin and Heinrich.
I had to rebuild toolchain by bumping up prctl (prctl conflict in 7.0 merge led
to landing pad prctls bumping by 1)
Jesse/Kito,
So you might want to do that as well before sending out next iteration of libc
changes.
Rest inline.
On Tue, Feb 24, 2026 at 05:57:52PM +0000, Catalin Marinas wrote:
>Hi,
>
>arm64, riscv and x86 all implement shadow stack support and use a
>similar pattern for mapping the user shadow stack (originally cloned
>from x86). Extract this common pattern into a shared helper -
>vm_mmap_shadow_stack().
>
>Patch 1 introduces vm_mmap_shadow_stack() in mm/util.c, which wraps
>do_mmap() with the flags required for a VM_SHADOW_STACK mapping. The
>helper uses PROT_READ|PROT_WRITE prot bits instead of the earlier x86
>approach of PROT_READ with an explicit VM_WRITE vm_flag. Functionally
>there is no difference. I looked up the history of this flag on the
>lists but it wasn't conclusive. My guess is that the original aim was to
>mark the vma not writable but that would confuse the kernel, so it ended
>up with the VM_WRITE flag instead.
>
>Patches 2-4 update arm64, riscv and x86 respectively to use the new
>helper, removing the duplicated mmap logic.
>
>Patch 5 forces VM_NOHUGEPAGE when allocating the shadow stack via the
>new helper, mirroring what commit c4608d1bf7c6 ("mm: mmap: map MAP_STACK
>to VM_NOHUGEPAGE") did for normal stacks. It will save some memory,
>especially when the ulimit -s is high.
>
>Boot-tested on x86, fully tested on arm64. I do not have a compiler
>version that supports the -march=rv64ima_zicfiss_zicfilp option for
>riscv, so any help with testing is welcome.
Catalin,
FWIW, I applied your patches on v7.0-rc1 and risc-v cfi kselftest passes
# ./cfitests
TAP version 13
# Starting risc-v tests
# Landing pad and shadow stack are enabled for binary
# cfi_ptrace_test, ptrace test succeeded
# Executing RISC-V shadow stack self tests
1..5
# Exercising shadow stack fork test
# Parent pid 130 and child pid 132
# dummy calls for sspush and sspopchk in context of parent
# Spewing out shadow stack ptr: 7fff914b7fb8
This is to ensure shadow stack is indeed enabled and working
# Waiting on child to finish
# dummy calls for sspush and sspopchk in context of child
# Spewing out shadow stack ptr: 7fff914b7fb8
This is to ensure shadow stack is indeed enabled and working
ok 1 shstk fork test
# Exercising shadow stack map test
ok 2 map shadow stack syscall
# Exercising shadow stack gup tests
ok 3 shadow stack gup tests
# Exercising shadow stack signal test
ok 4 shadow stack signal tests
# Exercising shadow stack protection test (WPT)
ok 5 memory protections of shadow stack memory
# Totals: pass:5 fail:0 xfail:0 xpass:0 skip:0 error:0
#
So you can tag tested by for risc-v.
>
>Thanks.
>
>Catalin Marinas (5):
> mm: Introduce vm_mmap_shadow_stack() as a helper for VM_SHADOW_STACK
> mappings
> arm64: gcs: Use the new common vm_mmap_shadow_stack() helper
> riscv: shstk: Use the new common vm_mmap_shadow_stack() helper
> x86: shstk: Use the new common vm_mmap_shadow_stack() helper
> mm: Do not map the shadow stack as THP
>
> arch/arm64/mm/gcs.c | 14 +-------------
> arch/riscv/kernel/usercfi.c | 12 +-----------
> arch/x86/kernel/shstk.c | 12 ++----------
> include/linux/mm.h | 4 ++++
> mm/util.c | 29 +++++++++++++++++++++++++++++
> 5 files changed, 37 insertions(+), 34 deletions(-)
>
WARNING: multiple messages have this Message-ID (diff)
From: Deepak Gupta <debug@rivosinc.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Mark Brown <broonie@kernel.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Will Deacon <will@kernel.org>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Kito Cheng <kito.cheng@sifive.com>,
Jesse Huang <jesse.huang@sifive.com>,
valentin.haudiquet@canonical.com,
heinrich.schuchardt@canonical.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-mm@kvack.org
Subject: Re: [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE
Date: Tue, 24 Feb 2026 16:06:13 -0800 [thread overview]
Message-ID: <aZ489QDHxEZfLydn@debug.ba.rivosinc.com> (raw)
In-Reply-To: <20260224175800.2500729-1-catalin.marinas@arm.com>
+ Kito, Jesse, Valentin and Heinrich.
I had to rebuild toolchain by bumping up prctl (prctl conflict in 7.0 merge led
to landing pad prctls bumping by 1)
Jesse/Kito,
So you might want to do that as well before sending out next iteration of libc
changes.
Rest inline.
On Tue, Feb 24, 2026 at 05:57:52PM +0000, Catalin Marinas wrote:
>Hi,
>
>arm64, riscv and x86 all implement shadow stack support and use a
>similar pattern for mapping the user shadow stack (originally cloned
>from x86). Extract this common pattern into a shared helper -
>vm_mmap_shadow_stack().
>
>Patch 1 introduces vm_mmap_shadow_stack() in mm/util.c, which wraps
>do_mmap() with the flags required for a VM_SHADOW_STACK mapping. The
>helper uses PROT_READ|PROT_WRITE prot bits instead of the earlier x86
>approach of PROT_READ with an explicit VM_WRITE vm_flag. Functionally
>there is no difference. I looked up the history of this flag on the
>lists but it wasn't conclusive. My guess is that the original aim was to
>mark the vma not writable but that would confuse the kernel, so it ended
>up with the VM_WRITE flag instead.
>
>Patches 2-4 update arm64, riscv and x86 respectively to use the new
>helper, removing the duplicated mmap logic.
>
>Patch 5 forces VM_NOHUGEPAGE when allocating the shadow stack via the
>new helper, mirroring what commit c4608d1bf7c6 ("mm: mmap: map MAP_STACK
>to VM_NOHUGEPAGE") did for normal stacks. It will save some memory,
>especially when the ulimit -s is high.
>
>Boot-tested on x86, fully tested on arm64. I do not have a compiler
>version that supports the -march=rv64ima_zicfiss_zicfilp option for
>riscv, so any help with testing is welcome.
Catalin,
FWIW, I applied your patches on v7.0-rc1 and risc-v cfi kselftest passes
# ./cfitests
TAP version 13
# Starting risc-v tests
# Landing pad and shadow stack are enabled for binary
# cfi_ptrace_test, ptrace test succeeded
# Executing RISC-V shadow stack self tests
1..5
# Exercising shadow stack fork test
# Parent pid 130 and child pid 132
# dummy calls for sspush and sspopchk in context of parent
# Spewing out shadow stack ptr: 7fff914b7fb8
This is to ensure shadow stack is indeed enabled and working
# Waiting on child to finish
# dummy calls for sspush and sspopchk in context of child
# Spewing out shadow stack ptr: 7fff914b7fb8
This is to ensure shadow stack is indeed enabled and working
ok 1 shstk fork test
# Exercising shadow stack map test
ok 2 map shadow stack syscall
# Exercising shadow stack gup tests
ok 3 shadow stack gup tests
# Exercising shadow stack signal test
ok 4 shadow stack signal tests
# Exercising shadow stack protection test (WPT)
ok 5 memory protections of shadow stack memory
# Totals: pass:5 fail:0 xfail:0 xpass:0 skip:0 error:0
#
So you can tag tested by for risc-v.
>
>Thanks.
>
>Catalin Marinas (5):
> mm: Introduce vm_mmap_shadow_stack() as a helper for VM_SHADOW_STACK
> mappings
> arm64: gcs: Use the new common vm_mmap_shadow_stack() helper
> riscv: shstk: Use the new common vm_mmap_shadow_stack() helper
> x86: shstk: Use the new common vm_mmap_shadow_stack() helper
> mm: Do not map the shadow stack as THP
>
> arch/arm64/mm/gcs.c | 14 +-------------
> arch/riscv/kernel/usercfi.c | 12 +-----------
> arch/x86/kernel/shstk.c | 12 ++----------
> include/linux/mm.h | 4 ++++
> mm/util.c | 29 +++++++++++++++++++++++++++++
> 5 files changed, 37 insertions(+), 34 deletions(-)
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-02-25 0:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 17:57 [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-24 17:57 ` [PATCH 1/5] mm: Introduce vm_mmap_shadow_stack() as a helper for VM_SHADOW_STACK mappings Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-24 19:47 ` Edgecombe, Rick P
2026-02-24 19:47 ` Edgecombe, Rick P
2026-02-25 12:25 ` Mark Brown
2026-02-25 12:25 ` Mark Brown
2026-02-25 13:32 ` David Hildenbrand (Arm)
2026-02-25 13:32 ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 2/5] arm64: gcs: Use the new common vm_mmap_shadow_stack() helper Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-25 13:32 ` David Hildenbrand (Arm)
2026-02-25 13:32 ` David Hildenbrand (Arm)
2026-02-25 13:41 ` Mark Brown
2026-02-25 13:41 ` Mark Brown
2026-02-24 17:57 ` [PATCH 3/5] riscv: shstk: " Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-25 13:33 ` David Hildenbrand (Arm)
2026-02-25 13:33 ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 4/5] x86: " Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-24 19:47 ` Edgecombe, Rick P
2026-02-24 19:47 ` Edgecombe, Rick P
2026-02-25 8:12 ` Catalin Marinas
2026-02-25 8:12 ` Catalin Marinas
2026-02-25 13:33 ` David Hildenbrand (Arm)
2026-02-25 13:33 ` David Hildenbrand (Arm)
2026-02-24 17:57 ` [PATCH 5/5] mm: Do not map the shadow stack as THP Catalin Marinas
2026-02-24 17:57 ` Catalin Marinas
2026-02-25 13:02 ` Mark Brown
2026-02-25 13:02 ` Mark Brown
2026-02-25 15:51 ` Catalin Marinas
2026-02-25 15:51 ` Catalin Marinas
2026-02-25 16:10 ` Mark Brown
2026-02-25 16:10 ` Mark Brown
2026-02-25 13:34 ` David Hildenbrand (Arm)
2026-02-25 13:34 ` David Hildenbrand (Arm)
2026-02-25 0:06 ` Deepak Gupta [this message]
2026-02-25 0:06 ` [PATCH 0/5] mm: arch/shstk: Common shadow stack mapping helper and VM_NOHUGEPAGE Deepak Gupta
2026-02-25 8:08 ` Catalin Marinas
2026-02-25 8:08 ` 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=aZ489QDHxEZfLydn@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=heinrich.schuchardt@canonical.com \
--cc=hpa@zytor.com \
--cc=jesse.huang@sifive.com \
--cc=kito.cheng@sifive.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=tglx@kernel.org \
--cc=valentin.haudiquet@canonical.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.