On Tue, Dec 12, 2023 at 08:17:09PM +0000, Edgecombe, Rick P wrote: > On Wed, 2023-11-22 at 09:42 +0000, Mark Brown wrote: > > These features are expected to be inherited by new threads and > > cleared > > on exec(), unknown features should be rejected for enable but > > accepted > > for locking (in order to allow for future proofing). > The reason why I stuck with arch_prctl when this came up is that CRIU > (and probably other ptracers) needs a way to unlock via ptrace. ptrace > arch_prctl() can do this. Did you have a plan for unlocking via ptrace? 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. 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.
Attachment:
signature.asc
Description: PGP signature
