linux-kernel - [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240125062739.1339782-11-debug@rivosinc.com>
Date: Wed, 24 Jan 2024 22:21:35 -0800
From: debug@...osinc.com
To: rick.p.edgecombe@...el.com,
	broonie@...nel.org,
	Szabolcs.Nagy@....com,
	kito.cheng@...ive.com,
	keescook@...omium.org,
	ajones@...tanamicro.com,
	paul.walmsley@...ive.com,
	palmer@...belt.com,
	conor.dooley@...rochip.com,
	cleger@...osinc.com,
	atishp@...shpatra.org,
	alex@...ti.fr,
	bjorn@...osinc.com,
	alexghiti@...osinc.com
Cc: corbet@....net,
	aou@...s.berkeley.edu,
	oleg@...hat.com,
	akpm@...ux-foundation.org,
	arnd@...db.de,
	ebiederm@...ssion.com,
	shuah@...nel.org,
	brauner@...nel.org,
	debug@...osinc.com,
	guoren@...nel.org,
	samitolvanen@...gle.com,
	evan@...osinc.com,
	xiao.w.wang@...el.com,
	apatel@...tanamicro.com,
	mchitale@...tanamicro.com,
	waylingii@...il.com,
	greentime.hu@...ive.com,
	heiko@...ech.de,
	jszhang@...nel.org,
	shikemeng@...weicloud.com,
	david@...hat.com,
	charlie@...osinc.com,
	panqinglin2020@...as.ac.cn,
	willy@...radead.org,
	vincent.chen@...ive.com,
	andy.chiu@...ive.com,
	gerg@...nel.org,
	jeeheng.sia@...rfivetech.com,
	mason.huo@...rfivetech.com,
	ancientmodern4@...il.com,
	mathis.salmen@...sal.de,
	cuiyunhui@...edance.com,
	bhe@...hat.com,
	chenjiahao16@...wei.com,
	ruscur@...sell.cc,
	bgray@...ux.ibm.com,
	alx@...nel.org,
	baruch@...s.co.il,
	zhangqing@...ngson.cn,
	catalin.marinas@....com,
	revest@...omium.org,
	josh@...htriplett.org,
	joey.gouly@....com,
	shr@...kernel.io,
	omosnace@...hat.com,
	ojeda@...nel.org,
	jhubbard@...dia.com,
	linux-doc@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	linux-arch@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT_SHADOWSTACK"

From: Deepak Gupta <debug@...osinc.com>

x86 and arm64 are using VM_SHADOW_STACK (which actually is VM_HIGH_ARCH_5)
vma flag and thus restrict it to 64bit implementation only. RISC-V is choosing
to encode presence of only VM_WRITE in vma flags as shadow stack vma. This allows
32bit RISC-V ecosystem leverage shadow stack as well.
This means that existing users of `do_mmap` who had been using `VM_WRITE` and
expecting read and write permissions will break.
Thus introducing `PROT_SHADOWSTACK` to allow `do_mmap` disambiguate between
read write v/s shadow stack mappings. Thus any kernel driver/module using `do_mmap`
and only passing `VM_WRITE` would still get read-write mappings. Although any user
of `do_mmap` intending to map a shaodw stack should pass `PROT_SHADOWSTACK` to get
a shadow stack mapping.

Although for userspace still want to rely on `map_shadow_stack` and not expose
`PROT_SHADOWSTACK` to userspace and that's why this prot flag is not exposed in uapi
headers.

Signed-off-by: Deepak Gupta <debug@...osinc.com>
---
 arch/riscv/include/asm/mman.h | 25 +++++++++++++++++++++++++
 mm/mmap.c                     |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 arch/riscv/include/asm/mman.h

diff --git a/arch/riscv/include/asm/mman.h b/arch/riscv/include/asm/mman.h
new file mode 100644
index 000000000000..4902d837e93c
--- /dev/null
+++ b/arch/riscv/include/asm/mman.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_MMAN_H__
+#define __ASM_MMAN_H__
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+#include <uapi/asm/mman.h>
+
+/*
+ * Major architectures (x86, aarch64, riscv) have shadow stack now. x86 and
+ * arm64 choose to use VM_SHADOW_STACK (which actually is VM_HIGH_ARCH_5) vma
+ * flag, however that restrict it to 64bit implementation only. risc-v shadow
+ * stack encodings in page tables is PTE.R=0, PTE.W=1, PTE.D=1 which used to be
+ * reserved until now. risc-v is choosing to encode presence of only VM_WRITE in
+ * vma flags as shadow stack vma. However this means that existing users of mmap
+ * (and do_mmap) who were relying on passing only PROT_WRITE (or VM_WRITE from
+ * kernel driver) but still getting read and write mappings, should still work.
+ * x86 and arm64 followed the direction of a new system call `map_shadow_stack`.
+ * risc-v would like to converge on that so that shadow stacks flows are as much
+ * arch agnostic. Thus a conscious decision to define PROT_XXX definition for
+ * shadow stack here (and not exposed to uapi)
+ */
+#define PROT_SHADOWSTACK	0x40
+
+#endif /* ! __ASM_MMAN_H__ */
diff --git a/mm/mmap.c b/mm/mmap.c
index 1971bfffcc03..fab2acf21ce9 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -47,6 +47,7 @@
 #include <linux/oom.h>
 #include <linux/sched/mm.h>
 #include <linux/ksm.h>
+#include <linux/processor.h>
 
 #include <linux/uaccess.h>
 #include <asm/cacheflush.h>
-- 
2.43.0