Thread (28 messages) 28 messages, 5 authors, 2024-10-03

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

From: Mark Brown <broonie@kernel.org>
Date: 2024-08-21 00:19:37
Also in: linux-kselftest, lkml

On Tue, Aug 20, 2024 at 11:57:23PM +0000, Edgecombe, Rick P wrote:
On Wed, 2024-08-21 at 00:34 +0100, Mark Brown wrote:
quoted
I was doing things this way for symmetry with how we specify the normal
stack.  That's a bit different since the kernel will actually use the
size for the normal stack but it felt nicer to keep things looking
consistent, it saves users wondering why they work differently.  It's
also a bit of a help with portability given that arm64 expects to have a
top of stack marker above the token by default while x86 doesn't support
that.
Hmm, so then on arm the kernel would look for the token down a frame. Hmm. I
think it makes it even stranger ABI wise.
I think it's going to be strange one way or another, either you specify
a size that we don't currently really use or you have two things both
called stacks which are described differently.  I suppose we could call
a single parameter shadow_stack_pointer?  Though I do note that as you
indicated we've been going for some time and this is the first time it
came up...
SHADOW_STACK_SET_MARKER can be optional (not on arm, but could be in the
future). Then the shadow_stack_size to token offset behavior would depend on
some historical originally supported combination of map_shadow_stack args.
I called it _SET_TOKEN, it's optional on arm64 - we check both potential
locations for the token in clone3().
BTW, just to try to reduce potential future revisions, what do you think about
the 8 byte alignment need? Did I miss the check somewhere?
I've added a check that both the base address and size are sizeof(void *)
aligned.

Attachments

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