Thread (52 messages) 52 messages, 6 authors, 2024-10-29

Re: [PATCH v6 16/33] riscv/shstk: If needed allocate a new shadow stack on clone

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2024-10-08 23:31:21
Also in: linux-arch, linux-devicetree, linux-fsdevel, linux-kselftest, linux-mm, linux-riscv, lkml

On Tue, 2024-10-08 at 16:17 -0700, Deepak Gupta wrote:
Yeah you're right. Honestly, I've been shameless in adapting most of the flows
from x86 `shstk.c` for risc-v. So thank you for that.
All good, glad we ended up with similar behavior.
Now that we've `ARCH_HAS_USER_SHADOW_STACK` part of multiple patch series (riscv
shadowstack, clone3 and I think arm64 gcs series as well). It's probably the
appropriate time to find common grounds.
There have been bugs in the similar bits of code. So will be nice to not have to
fix them in each arch too.
This is what I suggest

- move most of the common/arch agnostic shadow stack stuff in kernel/shstk.c
   This gets part of compile if `ARCH_HAS_USER_SHADOW_STACK` is enabled/selected.
Yea, I guess we have commonality for (in x86 naming):
 - map_shadow_stack()
 - shstk_free()
 - shstk_alloc_thread_stack()
 - shstk_setup()

The signal part starts to diverge. Then I guess x86 has a different prctl
interface.
- allow arch specific branch out guard checks for "if cpu supports", "is shadow stack
   enabled on the task_struct" (I expect each arch layout of task_struct will be
   different, no point finding common ground there), etc.
Sure.
I think it's worth a try. 
If you already don't have patches, I'll spend some time to see what it takes to
converge in my next version. If I end up into some roadblock, will use this thread
for further discussion.
Sounds good. I have not looked at it too much.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help