Thread (32 messages) 32 messages, 5 authors, 2023-11-20

Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2023-11-16 18:34:00
Also in: linux-kselftest, lkml

On Thu, 2023-11-16 at 18:14 +0000, Mark Brown wrote:
On Thu, Nov 16, 2023 at 12:52:09AM +0000, Edgecombe, Rick P wrote:
quoted
On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:
quoted
quoted
end marker token (0) needs it i guess.
quoted
quoted
x86 doesn't currently have end markers.  Actually, that's a point
-
should we add a flag for specifying the use of end markers here?
There's code in my map_shadow_stack() implementation for arm64
which
does that.
quoted
Hmm, I guess there isn't a way to pass a flag for the initial exec
stack? So probably it should just mirror that behavior. Unless you
think a lot of people would like to skip the default behavior.
I don't really know that anyone would particularly want to use a flag
on
arm64, I was more thinking for the benefit of x86 where any
termination
record would be a change.  It's certainly easier to not have flags so
I'm more than happy to leave things as they are, there's nothing
stopping further extensions of the ABI if we decide we want them
later.
I'm hoping that shifting the shadow stack start by one frame for thread
stacks (where there is no token to find) will not disturb anything. But
for x86, we will need a new elf bit to be fully safe in implementing
alt shadow stack. When we do that we will have a chance to add an end
of stack marker without compatibility issues on x86. So just doing
default behavior seems fine.

For map_shadow_stack, the end of stack marker will shift the token,
which userspace needs to find, so that is why I wanted a flag for that.
Appreciate the consideration.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help