All of lore.kernel.org
 help / color / mirror / Atom feed
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 17/20] riscv ucontext: adding shadow stack pointer field in ucontext
Date: Sun, 12 Feb 2023 20:53:46 -0800	[thread overview]
Message-ID: <20230213045351.3945824-18-debug@rivosinc.com> (raw)
In-Reply-To: <20230213045351.3945824-1-debug@rivosinc.com>

Shadow stack needs to be saved and restored on signal delivery and
signal return.

ucontext structure on riscv has existing large padding for possible
future extension of uc_sigmask. This patch steals XLEN/8 bytes from
padding to keep structure size and offset of existing member fields
same.

Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
 arch/riscv/include/uapi/asm/ucontext.h | 32 +++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/uapi/asm/ucontext.h b/arch/riscv/include/uapi/asm/ucontext.h
index 516bd0bb0da5..72303e5618a1 100644
--- a/arch/riscv/include/uapi/asm/ucontext.h
+++ b/arch/riscv/include/uapi/asm/ucontext.h
@@ -21,9 +21,12 @@ struct ucontext {
 	 * at the end of this structure and explicitly state it can be
 	 * expanded, so we didn't want to box ourselves in here.
 	 */
-	__u8		  __unused[1024 / 8 - sizeof(sigset_t)];
-	/*
-	 * We can't put uc_sigmask at the end of this structure because we need
+	__u8		  __unused[1024 / 8 - sizeof(sigset_t)
+#ifdef CONFIG_USER_SHADOW_STACK
+				   - sizeof(unsigned long)
+#endif
+				  ];
+	/* We can't put uc_sigmask at the end of this structure because we need
 	 * to be able to expand sigcontext in the future.  For example, the
 	 * vector ISA extension will almost certainly add ISA state.  We want
 	 * to ensure all user-visible ISA state can be saved and restored via a
@@ -31,7 +34,30 @@ struct ucontext {
 	 * infinite extensibility.  Since we know this will be extended and we
 	 * assume sigset_t won't be extended an extreme amount, we're
 	 * prioritizing this.
+	 */				  
+
+	/*
+	 * Zisslpcfi will need state in ucontext to save and restore across
+	 * makecontext/setcontext. Such one state is shadow stack pointer. We may need
+	 * to save label (of the target function) as well (but that's to be decided).
+	 * Stealing 8 (64bit) / 4 (32bit) bytes from padding (__unused) reserved
+	 * for expanding sigset_t. We could've expanded the size of ucontext. But
+	 * shadow stack is something which by default would be enabled via ELF.
+	 * ucontext expansion makes more sense for situations like vector where
+	 * app is willingly opting in to get special functionality. Opt-in allows
+	 * for enlightening in ucontext restore. Second reason is shadow stack
+	 * doesn't need a lot of state and only shadow stack pointer. Tax on
+	 * ecosystem due to a small size change (8 bytes) of ucontext is more than
+	 * simply keeping the size same and shoving the ss pointer in here. Please
+	 * note that shadow stack pointer is pointing to a shadow stack address.
+	 * Shadow stack address has shadow stack restore token using which shadow
+	 * stack should be restored.
+	 * Please note that we're keeping uc_ss_ptr at that this location so that
+	 * every other offsets are same and thus works for compatibility.
 	 */
+#ifdef CONFIG_USER_SHADOW_STACK
+	unsigned long uc_ss_ptr;
+#endif
 	struct sigcontext uc_mcontext;
 };
 
-- 
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 17/20] riscv ucontext: adding shadow stack pointer field in ucontext
Date: Sun, 12 Feb 2023 20:53:46 -0800	[thread overview]
Message-ID: <20230213045351.3945824-18-debug@rivosinc.com> (raw)
In-Reply-To: <20230213045351.3945824-1-debug@rivosinc.com>

Shadow stack needs to be saved and restored on signal delivery and
signal return.

ucontext structure on riscv has existing large padding for possible
future extension of uc_sigmask. This patch steals XLEN/8 bytes from
padding to keep structure size and offset of existing member fields
same.

Signed-off-by: Deepak Gupta <debug@rivosinc.com>
---
 arch/riscv/include/uapi/asm/ucontext.h | 32 +++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/uapi/asm/ucontext.h b/arch/riscv/include/uapi/asm/ucontext.h
index 516bd0bb0da5..72303e5618a1 100644
--- a/arch/riscv/include/uapi/asm/ucontext.h
+++ b/arch/riscv/include/uapi/asm/ucontext.h
@@ -21,9 +21,12 @@ struct ucontext {
 	 * at the end of this structure and explicitly state it can be
 	 * expanded, so we didn't want to box ourselves in here.
 	 */
-	__u8		  __unused[1024 / 8 - sizeof(sigset_t)];
-	/*
-	 * We can't put uc_sigmask at the end of this structure because we need
+	__u8		  __unused[1024 / 8 - sizeof(sigset_t)
+#ifdef CONFIG_USER_SHADOW_STACK
+				   - sizeof(unsigned long)
+#endif
+				  ];
+	/* We can't put uc_sigmask at the end of this structure because we need
 	 * to be able to expand sigcontext in the future.  For example, the
 	 * vector ISA extension will almost certainly add ISA state.  We want
 	 * to ensure all user-visible ISA state can be saved and restored via a
@@ -31,7 +34,30 @@ struct ucontext {
 	 * infinite extensibility.  Since we know this will be extended and we
 	 * assume sigset_t won't be extended an extreme amount, we're
 	 * prioritizing this.
+	 */				  
+
+	/*
+	 * Zisslpcfi will need state in ucontext to save and restore across
+	 * makecontext/setcontext. Such one state is shadow stack pointer. We may need
+	 * to save label (of the target function) as well (but that's to be decided).
+	 * Stealing 8 (64bit) / 4 (32bit) bytes from padding (__unused) reserved
+	 * for expanding sigset_t. We could've expanded the size of ucontext. But
+	 * shadow stack is something which by default would be enabled via ELF.
+	 * ucontext expansion makes more sense for situations like vector where
+	 * app is willingly opting in to get special functionality. Opt-in allows
+	 * for enlightening in ucontext restore. Second reason is shadow stack
+	 * doesn't need a lot of state and only shadow stack pointer. Tax on
+	 * ecosystem due to a small size change (8 bytes) of ucontext is more than
+	 * simply keeping the size same and shoving the ss pointer in here. Please
+	 * note that shadow stack pointer is pointing to a shadow stack address.
+	 * Shadow stack address has shadow stack restore token using which shadow
+	 * stack should be restored.
+	 * Please note that we're keeping uc_ss_ptr at that this location so that
+	 * every other offsets are same and thus works for compatibility.
 	 */
+#ifdef CONFIG_USER_SHADOW_STACK
+	unsigned long uc_ss_ptr;
+#endif
 	struct sigcontext uc_mcontext;
 };
 
-- 
2.25.1


  parent reply	other threads:[~2023-02-13  4:55 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 ` [PATCH v1 RFC Zisslpcfi 10/20] riscv mmu: write protect and shadow stack Deepak Gupta
2023-02-13  4:53   ` 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 ` Deepak Gupta [this message]
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 ` [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-18-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.