linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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(-)
>


      parent reply	other threads:[~2026-02-25  0:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 19:47   ` Edgecombe, Rick P
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 ` [PATCH 3/5] riscv: shstk: " Catalin Marinas
2026-02-24 17:57 ` [PATCH 4/5] x86: " Catalin Marinas
2026-02-24 19:47   ` Edgecombe, Rick P
2026-02-24 17:57 ` [PATCH 5/5] mm: Do not map the shadow stack as THP Catalin Marinas
2026-02-25  0:06 ` Deepak Gupta [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox