On Tue, Dec 12, 2023 at 09:22:59PM +0000, Edgecombe, Rick P wrote:
On Tue, 2023-12-12 at 20:26 +0000, Mark Brown wrote:
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.
It feels like x86 is doing some things via arch_prctl() rather than implementing specific ptrace() interfaces for them, there's a lot of stuff where ptrace isn't a great fit for due to it's concept that it's going to work with an array of registers so that's understandable.
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.
I don't have a strong enough opinion on it to start working on it immediately at any rate.