From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f67.google.com (mail-dl1-f67.google.com [74.125.82.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 031103EBF24 for ; Wed, 25 Feb 2026 00:06:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.67 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771977978; cv=none; b=Nlnd1Af4hAl/bK4/eM59TI05Fy60ve6D7279tYSeeFyWVLL7sr3UydL7wgG/VRaq2UHMctkHIcXfJZo1tOQMj5A5m+Zgf1LXk9kuaVRSM+kTaddr3dhZcNmSLOMgm1Dk6O3Ow2E1AVPXPgzIAE7z+E1pSGN8XTQcXwKczBnhwBQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771977978; c=relaxed/simple; bh=gUkSwft4ovs0mhXdSLN6nwxTtXf2lfu+SMs0XKwWp6I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dV6xIIFr7O9uRp9Gc4KD8Z3q4KS4RXvubTTjBKPf/XlR3s2rt5x/hi5NIYAPhYgGFx6cQAQVVuvEHIzr1r8aUnOdrOR0Nb0VArACR7+PtRuITJm1OX9LvWCF0GUL6A2IXqdvkvWMw28LBiNeEOBotpbpkcpg3RwhNdGLPrA5NUA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b=d45oIeS6; arc=none smtp.client-ip=74.125.82.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc.com header.i=@rivosinc.com header.b="d45oIeS6" Received: by mail-dl1-f67.google.com with SMTP id a92af1059eb24-12732165d1eso6688794c88.1 for ; Tue, 24 Feb 2026 16:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc.com; s=google; t=1771977976; x=1772582776; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2hwbo+qh3ZKjcL1ArZ2cEab76Y3DqcSCVeG8QenLMGQ=; b=d45oIeS6kC+1tmhdouJx4m23XT0EZdmJkaL9d196fb3I0Altaxlb+5KN70EgZJM/wb d6OCiY/M1jO7YOoqCrhTXJCb1oN0LnGw8+8wD2/XwKiFNRwRACrvm00pm5ux6NbDmslh diUFeFBbz3Da0c1BHDtH+5pALQXUNcDfBQFOl3tdSRbJGhBV0SktOC3roygt5Le+/c7E mlLY0To4JjZbHO7qdqkFt0xXWJbhd1Ma0beXTovbYJD32JRMYRxlmGCHfXPBNrNE9vPE S6BXCDAA6gXyYay8czdZZz3bozLjkwE5ugnjBZ4zKcmnfU4tM0i3Fp1P5+McitZfqtB1 vxpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771977976; x=1772582776; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2hwbo+qh3ZKjcL1ArZ2cEab76Y3DqcSCVeG8QenLMGQ=; b=G+771guXaJon3Oyp5XLZn1So93NbjsxdOtWb4rPOrZ12CKGIUeP1+Kq7QTVdEzGWtJ C1ojmtUwo9QchzAg1KHy909+aGrlQFMbXdXuBsWw0MPGl7fNcrJrMUvH24Kwl+rQb8Je oH7cl1sroQuOn54QaGwyg5rFVzDG2VJrdYXDjp+Q9naA6TK5wieHQj8/NLlYlo6MX0Cf 2k6ikOySEfUqt503xip1F7bU21PaxfvvT4xT8bpjizHuse9FS9hfjuw3c0DWxFpAVEVG HkSgux3AChJvXFmaFFILqZQJH91CfufS8oqK2sIoUWbKvQZpEyOkoqP2W6svz6m/Dv0g F3Ug== X-Forwarded-Encrypted: i=1; AJvYcCWzDRe09u2CC876hsfFxyUURqWrIW6cqUEjpIAktXTtjBxLFrThDBpEHWjhNl1HzrEtxM6BGNaU3rALvXk=@vger.kernel.org X-Gm-Message-State: AOJu0YyuYa/sx3TMdi/KHB7LODxEXzbktSj8Bz6zK9WvTPMw9RMhJhjM NCkIapU0TMbH82LDdA4nA5LjQXHoQyOYTZ+PqqJ3Ocq6j7iCqNdFKRhPIW4C3B5mjZo= X-Gm-Gg: ATEYQzykl2Sx0KeNRzAd27ZP0M87wc/qe/o9OEA/ui+A8nkbqmP77xJJa8+UN+Hs1Ed TyH8uIg0g1hJmI4CC81aW/DlqjpPvbt4KFmMoyulfcZyECO/6ThfW+nHD83NSjk89n/FTorWW6y Zom5Bmb7Hg0DnS2Vd4VXFjuFR3b01FkrNUakt9tr8rw/qKRU42xlHCgDz0o1rVB47QeHiYcseWi PdtdLFrJWvhsIcXIDJ+PU1pyq2sCbQ30/vF+16EMPDE1S57A4R9xku92MYanDYUk/X7O6DbBpZM QSyrCgub/W/v7CqtnTHZjcNpxcLKF5Onh5Oifl9YujtuWmOrAMHBiBE2cvk3W/neOrXQCPt++JB semqB9Nnm0gOke6vVK6t3gzJbXq+XsAj/yrfz9kk3mn/Gf44BPByf+ZOZi/HSjvy7FM9qQABaSh XQwpkldoS6qSr/0WDOp7B6Ma1KR+ted0gckAt5iJJb/0A= X-Received: by 2002:a05:7022:396:b0:127:c88:d597 with SMTP id a92af1059eb24-1276acec1a2mr5538246c88.10.1771977975966; Tue, 24 Feb 2026 16:06:15 -0800 (PST) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-1276af2edd7sm12707115c88.8.2026.02.24.16.06.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Feb 2026 16:06:15 -0800 (PST) Date: Tue, 24 Feb 2026 16:06:13 -0800 From: Deepak Gupta To: Catalin Marinas Cc: Andrew Morton , David Hildenbrand , Mark Brown , Rick Edgecombe , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Kito Cheng , Jesse Huang , 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 Message-ID: References: <20260224175800.2500729-1-catalin.marinas@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline 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(-) >