Thread (34 messages) 34 messages, 5 authors, 2024-08-16

Re: [PATCH RFT v8 4/9] fork: Add shadow stack support to clone3()

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2024-08-16 15:29:21
Also in: linux-kselftest, lkml

On Fri, Aug 16, 2024 at 11:51:57AM +0100, Mark Brown wrote:
On Fri, Aug 16, 2024 at 09:44:46AM +0100, Catalin Marinas wrote:
quoted
We could, in theory, consume this token in the parent before the child
mm is created. The downside is that if a parent forks multiple
processes using the same shadow stack, it will have to set the token
each time. I'd be fine with this, that's really only for the mostly
theoretical case where one doesn't use CLONE_VM and still want a
separate stack and shadow stack.
I originally implemented things that way but people did complain about
the !CLONE_VM case, which does TBH seem reasonable.  Note that the
parent won't as standard be able to set the token again - since the
shadow stack is not writable to userspace by default it'd instead need
to allocate a whole new shadow stack for each child.
Ah, good point.
I change back to parsing the token in the parent but I don't want to end
up in a cycle of bouncing between the two implementations depending on
who's reviewed the most recent version.
You and others spent a lot more time looking at shadow stacks than me.
I'm not necessarily asking to change stuff but rather understand the
choices made.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help