From: debug@rivosinc.com To: rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, paul.walmsley@sifive.com, palmer@dabbelt.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com Cc: corbet@lwn.net, aou@eecs.berkeley.edu, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, shuah@kernel.org, brauner@kernel.org, debug@rivosinc.com, guoren@kernel.org, samitolvanen@google.com, evan@rivosinc.com, xiao.w.wang@intel.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, waylingii@gmail.com, greentime.hu@sifive.com, heiko@sntech.de, jszhang@kernel.org, shikemeng@huaweicloud.com, david@redhat.com, charlie@rivosinc.com, panqinglin2020@iscas.ac.cn, willy@infradead.org, vincent.chen@sifive.com, andy.chiu@sifive.com, gerg@kernel.org, jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bhe@redhat.com, chenjiahao16@huawei.com, ruscur@russell.cc, bgray@linux.ibm.com, alx@kernel.org, baruch@tkos.co.il, zhangqing@loongson.cn, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com, shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [RFC PATCH v1 14/28] riscv mmu: write protect and shadow stack Date: Wed, 24 Jan 2024 22:21:39 -0800 [thread overview] Message-ID: <20240125062739.1339782-15-debug@rivosinc.com> (raw) In-Reply-To: <20240125062739.1339782-1-debug@rivosinc.com> From: Deepak Gupta <debug@rivosinc.com> `fork` implements copy on write (COW) by making pages readonly in child and parent both. ptep_set_wrprotect and pte_wrprotect clears _PAGE_WRITE in PTE. Assumption is that page is readable and on fault copy on write happens. To implement COW on such pages, clearing up W bit makes them XWR = 000. This will result in wrong PTE setting which says no perms but V=1 and PFN field pointing to final page. Instead desired behavior is to turn it into a readable page, take an access (load/store) fault on sspush/sspop (shadow stack) and then perform COW on such pages. This way regular reads would still be allowed and not lead to COW maintaining current behavior of COW on non-shadow stack but writeable memory. On the other hand it doesn't interfere with existing COW for read-write memory. Assumption is always that _PAGE_READ must have been set and thus setting _PAGE_READ is harmless. Signed-off-by: Deepak Gupta <debug@rivosinc.com> --- arch/riscv/include/asm/pgtable.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 9477108e727d..9802e8d48616 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -398,7 +398,7 @@ static inline int pte_special(pte_t pte) static inline pte_t pte_wrprotect(pte_t pte) { - return __pte(pte_val(pte) & ~(_PAGE_WRITE)); + return __pte((pte_val(pte) & ~(_PAGE_WRITE)) | (_PAGE_READ)); } /* static inline pte_t pte_mkread(pte_t pte) */ @@ -594,7 +594,15 @@ static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep) { - atomic_long_and(~(unsigned long)_PAGE_WRITE, (atomic_long_t *)ptep); + volatile pte_t read_pte = *ptep; + /* + * ptep_set_wrprotect can be called for shadow stack ranges too. + * shadow stack memory is XWR = 010 and thus clearing _PAGE_WRITE will lead to + * encoding 000b which is wrong encoding with V = 1. This should lead to page fault + * but we dont want this wrong configuration to be set in page tables. + */ + atomic_long_set((atomic_long_t *)ptep, + ((pte_val(read_pte) & ~(unsigned long)_PAGE_WRITE) | _PAGE_READ)); } #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH -- 2.43.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: debug@rivosinc.com To: rick.p.edgecombe@intel.com, broonie@kernel.org, Szabolcs.Nagy@arm.com, kito.cheng@sifive.com, keescook@chromium.org, ajones@ventanamicro.com, paul.walmsley@sifive.com, palmer@dabbelt.com, conor.dooley@microchip.com, cleger@rivosinc.com, atishp@atishpatra.org, alex@ghiti.fr, bjorn@rivosinc.com, alexghiti@rivosinc.com Cc: corbet@lwn.net, aou@eecs.berkeley.edu, oleg@redhat.com, akpm@linux-foundation.org, arnd@arndb.de, ebiederm@xmission.com, shuah@kernel.org, brauner@kernel.org, debug@rivosinc.com, guoren@kernel.org, samitolvanen@google.com, evan@rivosinc.com, xiao.w.wang@intel.com, apatel@ventanamicro.com, mchitale@ventanamicro.com, waylingii@gmail.com, greentime.hu@sifive.com, heiko@sntech.de, jszhang@kernel.org, shikemeng@huaweicloud.com, david@redhat.com, charlie@rivosinc.com, panqinglin2020@iscas.ac.cn, willy@infradead.org, vincent.chen@sifive.com, andy.chiu@sifive.com, gerg@kernel.org, jeeheng.sia@starfivetech.com, mason.huo@starfivetech.com, ancientmodern4@gmail.com, mathis.salmen@matsal.de, cuiyunhui@bytedance.com, bhe@redhat.com, chenjiahao16@huawei.com, ruscur@russell.cc, bgray@linux.ibm.com, alx@kernel.org, baruch@tkos.co.il, zhangqing@loongson.cn, catalin.marinas@arm.com, revest@chromium.org, josh@joshtriplett.org, joey.gouly@arm.com, shr@devkernel.io, omosnace@redhat.com, ojeda@kernel.org, jhubbard@nvidia.com, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [RFC PATCH v1 14/28] riscv mmu: write protect and shadow stack Date: Wed, 24 Jan 2024 22:21:39 -0800 [thread overview] Message-ID: <20240125062739.1339782-15-debug@rivosinc.com> (raw) In-Reply-To: <20240125062739.1339782-1-debug@rivosinc.com> From: Deepak Gupta <debug@rivosinc.com> `fork` implements copy on write (COW) by making pages readonly in child and parent both. ptep_set_wrprotect and pte_wrprotect clears _PAGE_WRITE in PTE. Assumption is that page is readable and on fault copy on write happens. To implement COW on such pages, clearing up W bit makes them XWR = 000. This will result in wrong PTE setting which says no perms but V=1 and PFN field pointing to final page. Instead desired behavior is to turn it into a readable page, take an access (load/store) fault on sspush/sspop (shadow stack) and then perform COW on such pages. This way regular reads would still be allowed and not lead to COW maintaining current behavior of COW on non-shadow stack but writeable memory. On the other hand it doesn't interfere with existing COW for read-write memory. Assumption is always that _PAGE_READ must have been set and thus setting _PAGE_READ is harmless. Signed-off-by: Deepak Gupta <debug@rivosinc.com> --- arch/riscv/include/asm/pgtable.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index 9477108e727d..9802e8d48616 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -398,7 +398,7 @@ static inline int pte_special(pte_t pte) static inline pte_t pte_wrprotect(pte_t pte) { - return __pte(pte_val(pte) & ~(_PAGE_WRITE)); + return __pte((pte_val(pte) & ~(_PAGE_WRITE)) | (_PAGE_READ)); } /* static inline pte_t pte_mkread(pte_t pte) */ @@ -594,7 +594,15 @@ static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep) { - atomic_long_and(~(unsigned long)_PAGE_WRITE, (atomic_long_t *)ptep); + volatile pte_t read_pte = *ptep; + /* + * ptep_set_wrprotect can be called for shadow stack ranges too. + * shadow stack memory is XWR = 010 and thus clearing _PAGE_WRITE will lead to + * encoding 000b which is wrong encoding with V = 1. This should lead to page fault + * but we dont want this wrong configuration to be set in page tables. + */ + atomic_long_set((atomic_long_t *)ptep, + ((pte_val(read_pte) & ~(unsigned long)_PAGE_WRITE) | _PAGE_READ)); } #define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH -- 2.43.0
next prev parent reply other threads:[~2024-01-25 6:30 UTC|newest] Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-25 6:21 [RFC PATCH v1 00/28] riscv control-flow integrity for usermode debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 01/28] riscv: abstract envcfg CSR debug 2024-01-25 6:21 ` debug 2024-02-12 10:23 ` Andrew Jones 2024-02-12 10:23 ` Andrew Jones 2024-01-25 6:21 ` [RFC PATCH v1 02/28] riscv: envcfg save and restore on trap entry/exit debug 2024-01-25 6:21 ` debug 2024-01-25 7:19 ` Stefan O'Rear 2024-01-25 7:19 ` Stefan O'Rear 2024-01-25 17:09 ` Deepak Gupta 2024-01-25 17:09 ` Deepak Gupta 2024-01-25 17:54 ` Deepak Gupta 2024-01-25 17:54 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 03/28] riscv: define default value for envcfg debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 04/28] riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 05/28] riscv: zicfiss/zicfilp enumeration debug 2024-01-25 6:21 ` debug 2024-01-25 17:59 ` Conor Dooley 2024-01-25 17:59 ` Conor Dooley 2024-01-25 18:26 ` Deepak Gupta 2024-01-25 18:26 ` Deepak Gupta 2024-01-25 18:46 ` Conor Dooley 2024-01-25 18:46 ` Conor Dooley 2024-01-25 6:21 ` [RFC PATCH v1 06/28] riscv: zicfiss/zicfilp extension csr and bit definitions debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 07/28] riscv: kernel handling on trap entry/exit for user cfi debug 2024-01-25 6:21 ` debug 2024-01-25 7:29 ` Stefan O'Rear 2024-01-25 7:29 ` Stefan O'Rear 2024-01-25 17:30 ` Deepak Gupta 2024-01-25 17:30 ` Deepak Gupta 2024-01-25 19:47 ` Stefan O'Rear 2024-01-25 19:47 ` Stefan O'Rear 2024-01-26 0:25 ` Deepak Gupta 2024-01-26 0:25 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 08/28] mm: Define VM_SHADOW_STACK for RISC-V debug 2024-01-25 6:21 ` debug 2024-01-25 8:17 ` David Hildenbrand 2024-01-25 8:17 ` David Hildenbrand 2024-01-25 17:05 ` Deepak Gupta 2024-01-25 17:05 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 09/28] mm: abstract shadow stack vma behind `arch_is_shadow_stack` debug 2024-01-25 6:21 ` debug 2024-01-25 8:18 ` David Hildenbrand 2024-01-25 8:18 ` David Hildenbrand 2024-01-25 17:07 ` Deepak Gupta 2024-01-25 17:07 ` Deepak Gupta 2024-02-13 10:34 ` David Hildenbrand 2024-02-13 10:34 ` David Hildenbrand 2024-02-22 1:32 ` Deepak Gupta 2024-02-22 1:32 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 10/28] riscv/mm : Introducing new protection flag "PROT_SHADOWSTACK" debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 11/28] riscv: Implementing "PROT_SHADOWSTACK" on riscv debug 2024-01-25 6:21 ` debug 2024-02-09 20:44 ` Edgecombe, Rick P 2024-02-09 20:44 ` Edgecombe, Rick P 2024-02-22 0:39 ` Deepak Gupta 2024-02-22 0:39 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 12/28] riscv mm: manufacture shadow stack pte debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 13/28] riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` debug [this message] 2024-01-25 6:21 ` [RFC PATCH v1 14/28] riscv mmu: write protect and shadow stack debug 2024-01-25 6:21 ` [RFC PATCH v1 15/28] riscv/mm: Implement map_shadow_stack() syscall debug 2024-01-25 6:21 ` debug 2024-01-25 21:24 ` Charlie Jenkins 2024-01-25 21:24 ` Charlie Jenkins 2024-01-26 0:44 ` Deepak Gupta 2024-01-26 0:44 ` Deepak Gupta 2024-02-06 16:01 ` Mark Brown 2024-02-06 16:01 ` Mark Brown 2024-02-22 0:47 ` Deepak Gupta 2024-02-22 0:47 ` Deepak Gupta 2024-02-22 13:33 ` Mark Brown 2024-02-22 13:33 ` Mark Brown 2024-02-09 20:44 ` Edgecombe, Rick P 2024-02-09 20:44 ` Edgecombe, Rick P 2024-02-22 0:50 ` Deepak Gupta 2024-02-22 0:50 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 16/28] riscv/shstk: If needed allocate a new shadow stack on clone debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 17/28] prctl: arch-agnostic prctl for shadow stack debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 18/28] prctl: arch-agnostic prtcl for indirect branch tracking debug 2024-01-25 6:21 ` debug 2024-02-06 16:13 ` Mark Brown 2024-02-06 16:13 ` Mark Brown 2024-02-22 0:42 ` Deepak Gupta 2024-02-22 0:42 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 19/28] riscv: Implements arch agnostic shadow stack prctls debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 20/28] riscv: Implements arch argnostic indirect branch tracking prctls debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 21/28] riscv/traps: Introduce software check exception debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 22/28] riscv sigcontext: adding cfi state field in sigcontext debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 23/28] riscv signal: Save and restore of shadow stack for signal debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 24/28] riscv: select config for shadow stack and landing pad instr support debug 2024-01-25 6:21 ` debug 2024-01-25 18:04 ` Conor Dooley 2024-01-25 18:04 ` Conor Dooley 2024-01-25 18:12 ` Deepak Gupta 2024-01-25 18:12 ` Deepak Gupta 2024-01-25 18:44 ` Conor Dooley 2024-01-25 18:44 ` Conor Dooley 2024-01-25 19:26 ` Deepak Gupta 2024-01-25 19:26 ` Deepak Gupta 2024-01-25 6:21 ` [RFC PATCH v1 25/28] riscv/ptrace: riscv cfi status and state via ptrace and in core files debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 26/28] riscv: Documentation for landing pad / indirect branch tracking debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 27/28] riscv: Documentation for shadow stack on riscv debug 2024-01-25 6:21 ` debug 2024-01-25 6:21 ` [RFC PATCH v1 28/28] kselftest/riscv: kselftest for user mode cfi debug 2024-01-25 6:21 ` debug
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=20240125062739.1339782-15-debug@rivosinc.com \ --to=debug@rivosinc.com \ --cc=Szabolcs.Nagy@arm.com \ --cc=ajones@ventanamicro.com \ --cc=akpm@linux-foundation.org \ --cc=alex@ghiti.fr \ --cc=alexghiti@rivosinc.com \ --cc=alx@kernel.org \ --cc=ancientmodern4@gmail.com \ --cc=andy.chiu@sifive.com \ --cc=aou@eecs.berkeley.edu \ --cc=apatel@ventanamicro.com \ --cc=arnd@arndb.de \ --cc=atishp@atishpatra.org \ --cc=baruch@tkos.co.il \ --cc=bgray@linux.ibm.com \ --cc=bhe@redhat.com \ --cc=bjorn@rivosinc.com \ --cc=brauner@kernel.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=charlie@rivosinc.com \ --cc=chenjiahao16@huawei.com \ --cc=cleger@rivosinc.com \ --cc=conor.dooley@microchip.com \ --cc=corbet@lwn.net \ --cc=cuiyunhui@bytedance.com \ --cc=david@redhat.com \ --cc=ebiederm@xmission.com \ --cc=evan@rivosinc.com \ --cc=gerg@kernel.org \ --cc=greentime.hu@sifive.com \ --cc=guoren@kernel.org \ --cc=heiko@sntech.de \ --cc=jeeheng.sia@starfivetech.com \ --cc=jhubbard@nvidia.com \ --cc=joey.gouly@arm.com \ --cc=josh@joshtriplett.org \ --cc=jszhang@kernel.org \ --cc=keescook@chromium.org \ --cc=kito.cheng@sifive.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mason.huo@starfivetech.com \ --cc=mathis.salmen@matsal.de \ --cc=mchitale@ventanamicro.com \ --cc=ojeda@kernel.org \ --cc=oleg@redhat.com \ --cc=omosnace@redhat.com \ --cc=palmer@dabbelt.com \ --cc=panqinglin2020@iscas.ac.cn \ --cc=paul.walmsley@sifive.com \ --cc=revest@chromium.org \ --cc=rick.p.edgecombe@intel.com \ --cc=ruscur@russell.cc \ --cc=samitolvanen@google.com \ --cc=shikemeng@huaweicloud.com \ --cc=shr@devkernel.io \ --cc=shuah@kernel.org \ --cc=vincent.chen@sifive.com \ --cc=waylingii@gmail.com \ --cc=willy@infradead.org \ --cc=xiao.w.wang@intel.com \ --cc=zhangqing@loongson.cn \ /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: linkBe 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.