From: Deepak Gupta <debug@rivosinc.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "Torvalds, Linus" <torvalds@linux-foundation.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"x86@kernel.org" <x86@kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Subject: Re: [GIT PULL] x86/shstk for 6.4
Date: Mon, 15 May 2023 14:22:55 -0700 [thread overview]
Message-ID: <20230515212255.GA562920@debug.ba.rivosinc.com> (raw)
In-Reply-To: <bd7c4f53cd27224308bff305513978dced1495ad.camel@intel.com>
On Sun, May 07, 2023 at 04:24:24PM +0000, Edgecombe, Rick P wrote:
>
>BTW, I forgot to mention that there is another architecture (maybe 2)
>that is expected to use this refactor for implementing their shadow
>stacks. So FWIW, this churn is not just for x86.
>
That's right, one of them is RISC-V.
RISC-V control-flow integrity: https://github.com/riscv/riscv-cfi
Since RISC-V PTE have 3 separate bits for read, write and execute. Write
only (R=0, W=1, X=0) encodings had been reserved and thus cpu supporting
this extension will treat this reserved encoding as shadow stack.
It doesn't get messy as in case of x86 (due to overloading of dirty bit),
but it still will need pte helper which marks a page "shadow stack
writeable" or "regular writeable" depending on vma.
I plan to use this re-factor for RISC-V shadow stack as well.
RISC-V CFI RFC
https://lore.kernel.org/lkml/20230213045351.3945824-1-debug@rivosinc.com/
Note: This is still a WIP. As spec gets into stable state, I'll post a v2.
On my patch pte helper discusion and suggestion to converge with x86 on
pte_mkwrite
https://lore.kernel.org/lkml/7693247c-a55d-a375-3621-1b07115a9d99@redhat.com/
-Deepak
next prev parent reply other threads:[~2023-05-15 21:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 21:21 [GIT PULL] x86/shstk for 6.4 Dave Hansen
2023-04-28 18:17 ` Linus Torvalds
2023-04-29 0:26 ` Edgecombe, Rick P
2023-04-29 0:40 ` Dave Hansen
2023-05-06 19:34 ` Linus Torvalds
2023-05-06 20:09 ` Linus Torvalds
2023-05-07 0:18 ` Edgecombe, Rick P
2023-05-07 0:38 ` Linus Torvalds
2023-05-07 15:57 ` Edgecombe, Rick P
2023-05-08 22:57 ` Dave Hansen
2023-05-08 23:31 ` Linus Torvalds
2023-05-08 23:47 ` Linus Torvalds
2023-05-12 17:34 ` Dave Hansen
2023-05-12 21:55 ` Linus Torvalds
2023-05-15 21:36 ` Dave Hansen
2023-05-15 21:37 ` Dave Hansen
2023-05-15 22:40 ` Linus Torvalds
2023-05-15 23:02 ` Linus Torvalds
2023-05-16 20:38 ` Linus Torvalds
2023-05-16 20:42 ` Dave Hansen
2023-05-09 0:07 ` Dave Hansen
2023-05-07 0:10 ` Edgecombe, Rick P
2023-05-07 0:19 ` Linus Torvalds
2023-05-07 16:24 ` Edgecombe, Rick P
2023-05-15 21:22 ` Deepak Gupta [this message]
2023-05-25 16:20 ` Mark Brown
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=20230515212255.GA562920@debug.ba.rivosinc.com \
--to=debug@rivosinc.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rick.p.edgecombe@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox