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

["Szabolcs.Nagy@arm.com" <Szabolcs.Nagy@arm.com>]

The 10/26/2023 13:40, Deepak Gupta wrote:
> On Thu, Oct 26, 2023 at 06:53:37PM +0100, Mark Brown wrote:
> > I'm not sure placement control is essential but the other bit of it is
> > the freeing of the shadow stack, especially if userspace is doing stack
> > switches the current behaviour where we free the stack when the thread
> > is exiting doesn't feel great exactly.  It's mainly an issue for
> > programs that pivot stacks which isn't the common case but it is a
> > general sharp edge.
>
> In general, I am assuming such placement requirements emanate because
> regular stack holds data (local args, etc) as well and thus software may
> make assumptions about how stack frame is prepared and may worry about
> layout and such. In case of shadow stack, it can only hold return

no. the lifetime is the issue: a stack in principle can outlive
a thread and resumed even after the original thread exited.
for that to work the shadow stack has to outlive the thread too.

(or the other way around: a stack can be freed before the thread
exits, if the thread pivots away from that stack.)

posix threads etc. don't allow this, but the linux syscall abi
(clone) does allow it.

i think it is reasonable to tie the shadow stack lifetime to the
thread lifetime, but this clearly introduces a limitation on how
the clone api can be used. such constraint on the userspace
programming model is normally a bad decision, but given that most
software (including all posix conforming code) is not affected,
i think it is acceptable for an opt-in feature like shadow stack.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.