[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230515212255.GA562920@debug.ba.rivosinc.com>
Date: Mon, 15 May 2023 14:22:55 -0700
From: Deepak Gupta <debug@...osinc.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "Torvalds, Linus" <torvalds@...ux-foundation.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"x86@...nel.org" <x86@...nel.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Subject: Re: [GIT PULL] x86/shstk for 6.4
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
Powered by blists - more mailing lists