Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack

On Wed, Aug 26, 2020 at 06:51:48PM +0200, Florian Weimer wrote:

* Dave Martin:

quoted

On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote:

quoted

On 8/25/2020 4:20 PM, Dave Hansen wrote:

quoted

On 8/25/20 2:04 PM, Yu, Yu-cheng wrote:

quoted

quoted

quoted

I think this is more arch-specific.  Even if it becomes a new syscall,
we still need to pass the same parameters.

Right, but without the copying in and out of memory.

Linux-api is already on the Cc list.  Do we need to add more people to
get some agreements for the syscall?

What kind of agreement are you looking for?  I'd suggest just coding it
up and posting the patches.  Adding syscalls really is really pretty
straightforward and isn't much code at all.

Sure, I will do that.

Alternatively, would a regular prctl() work here?

Is this something appliation code has to call, or just the dynamic
loader?

prctl in glibc is a variadic function, so if there's a mismatch between
the kernel/userspace syscall convention and the userspace calling
convention (for variadic functions) for specific types, it can't be made
to work in a generic way.

The loader can use inline assembly for system calls and does not have
this issue, but applications would be implcated by it.

To the extent that this is a problem, libc's prctl() wrapper has to
handle it already.  New prctl() calls tend to demand precisely 4
arguments and require unused arguments to be 0, but this is more down to
policy rather than because anything breaks otherwise.

You're right that this has implications: for i386, libc probably pulls
more arguments off the stack than are really there in some situations.
This isn't a new problem though.  There are already generic prctls with
fewer than 4 args that are used on x86.

Merging the actual prctl() and arch_prctl() syscalls doesn't acutally
stop libc from retaining separate wrappers if they have different
argument marshaling requirements in some corner cases.


There might be some underlying reason by x86 has its own call and nobody
else followed the same model, but I don't know what it is.

Cheers
---Dave