Re: [PATCH v7 02/39] prctl: arch-agnostic prctl for shadow stack

[Edgecombe, Rick P]

+Mike, who did the CRIU work

Re:
https://lore.kernel.org/lkml/e1362732ba86990b7707d3f5b785358b77c5f896.camel@xxxxxxxxx/

On Tue, 2023-12-12 at 20:26 +0000, Mark Brown wrote:
> The set of locked features is read/write via ptrace in my arm64
> series,
> that's architecture specific unfortunately but that seems to be the
> way
> with ptrace.

Ah, sorry I didn't see that later in the series. Makes sense. 

> 
> In general if things have a need to get at prctl()s via ptrace we
> should
> just fix that, at least for arm64 there's things like the vector
> lengths
> that are currently controlled via prctl(), but it shouldn't be a
> blocker
> for the locking specifically.

ptrace arch_prctl() is a bit odd. Not all values of 'option' are
supported because ptrace arch_prctl's have to operate cross task. Some
have extra code to support doing this, and some only know how to
operate on the current task, so return an error in the ptrace case.

I guess a benefit would be that there could be some arch agnostic
ptrace userspace code. And I'd also guess (really a guess) that most
ptracing code has some arch awareness already, but the other way is
probably non-zero. Same for shadow stack enabling code. Then on the
kernel side we'd have to add and support a ptrace prctl() solution.

Is it worth the effort? I don't have a strong opinion.