+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.
