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

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

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2024-08-20 23:57:27
Also in: linux-kselftest, lkml

On Wed, 2024-08-21 at 00:34 +0100, Mark Brown wrote:
quoted
Why do we need both shadow_stack and shadow_stack_size? We are basically
asking
it to consume a token at a pointer and have userspace manage the shadow
stack
itself. So why does the kernel care what size it is? Couldn't we just have
'shadow_stack' have that mean consume a token here.
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.

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.

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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help