From: Deepak Gupta <debug@rivosinc.com>
To: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>
Cc: Deepak Gupta <debug@rivosinc.com>
Subject: [PATCH v1 RFC Zisslpcfi 10/20] riscv mmu: write protect and shadow stack
Date: Sun, 12 Feb 2023 20:53:39 -0800 [thread overview]
Message-ID: <20230213045351.3945824-11-debug@rivosinc.com> (raw)
In-Reply-To: <20230213045351.3945824-1-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 74dbe122f2fa..13b325253c99 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -334,7 +334,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) */
@@ -509,7 +509,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.25.1
_______________________________________________
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: Deepak Gupta <debug@rivosinc.com>
To: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>
Cc: Deepak Gupta <debug@rivosinc.com>
Subject: [PATCH v1 RFC Zisslpcfi 10/20] riscv mmu: write protect and shadow stack
Date: Sun, 12 Feb 2023 20:53:39 -0800 [thread overview]
Message-ID: <20230213045351.3945824-11-debug@rivosinc.com> (raw)
In-Reply-To: <20230213045351.3945824-1-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 74dbe122f2fa..13b325253c99 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -334,7 +334,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) */
@@ -509,7 +509,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.25.1
next prev parent reply other threads:[~2023-02-13 6:00 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 4:53 [PATCH v1 RFC Zisslpcfi 00/20] riscv control-flow integrity for U mode Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 01/20] sslp stubs: shadow stack and landing pad stubs Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 02/20] riscv: zisslpcfi enumeration Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 03/20] riscv: zisslpcfi extension csr and bit definitions Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 04/20] riscv: kernel enabling user code for shadow stack and landing pad Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 05/20] mmap : Introducing new protection "PROT_SHADOWSTACK" for mmap Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 7:10 ` kernel test robot
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 06/20] riscv: Implementing "PROT_SHADOWSTACK" on riscv Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 07/20] elf: ELF header parsing in GNU property for cfi state Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 08/20] riscv: ELF header parsing in GNU property for riscv zisslpcfi Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 7:10 ` kernel test robot
2023-02-13 8:57 ` kernel test robot
2023-02-13 18:34 ` kernel test robot
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 09/20] riscv mmu: riscv shadow stack page fault handling Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 19:36 ` kernel test robot
2023-02-13 4:53 ` Deepak Gupta [this message]
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 10/20] riscv mmu: write protect and shadow stack Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 11/20] mmu: maybe_mkwrite updated to manufacture shadow stack PTEs Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 12:05 ` David Hildenbrand
2023-02-13 12:05 ` David Hildenbrand
2023-02-13 14:37 ` Deepak Gupta
2023-02-13 14:37 ` Deepak Gupta
2023-02-13 14:56 ` David Hildenbrand
2023-02-13 14:56 ` David Hildenbrand
2023-02-13 20:01 ` Deepak Gupta
2023-02-13 20:01 ` Deepak Gupta
2023-02-14 12:10 ` David Hildenbrand
2023-02-14 12:10 ` David Hildenbrand
2023-02-14 18:27 ` Edgecombe, Rick P
2023-02-14 18:27 ` Edgecombe, Rick P
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 12/20] riscv mm: manufacture shadow stack pte and is vma shadowstack Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 13/20] riscv: illegal instruction handler for cfi violations Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 14/20] riscv: audit mode " Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 15/20] sslp prctl: arch-agnostic prctl for shadow stack and landing pad instr Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 7:31 ` kernel test robot
2023-05-25 17:17 ` Mark Brown
2023-05-25 17:17 ` Mark Brown
2023-06-07 20:22 ` Mark Brown
2023-06-07 20:22 ` Mark Brown
2023-10-09 21:22 ` Deepak Gupta
2023-10-09 21:22 ` Deepak Gupta
2023-10-10 16:17 ` Mark Brown
2023-10-10 16:17 ` Mark Brown
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 16/20] riscv: Implements sslp prctls Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 17/20] riscv ucontext: adding shadow stack pointer field in ucontext Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 18/20] riscv signal: Save and restore of shadow stack for signal Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 19/20] config: adding two new config for control flow integrity Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
2023-02-13 4:53 ` [PATCH v1 RFC Zisslpcfi 20/20] riscv: select config for shadow stack and landing pad instr support Deepak Gupta
2023-02-13 4:53 ` Deepak Gupta
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=20230213045351.3945824-11-debug@rivosinc.com \
--to=debug@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/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.