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.
Attachment:
signature.asc
Description: PGP signature
