| Previous | Next |
| KERN_CODESIGN_ERROR | KERN_INSUFFICIENT_BUFFER_SIZE |
KERN_POLICY_STATIC
A policy change that the target thread does not accept
KERN_POLICY_STATIC means that the requested property cannot be changed at that point. For Mach thread-policy operations, this is different from a malformed request and different from a normal authorization failure: the target thread has static policy parameters, so the scheduler does not apply the requested change through that path.
Current XNU checks the thread’s static_param state before applying policy changes. Both the kernel implementation of thread_policy_set and the legacy absolute-priority path can return KERN_POLICY_STATIC for such a thread.
Why an application may not see code 51 directly
The public libsyscall wrappers for thread_policy_set, thread_policy, and thread_set_policy explicitly convert KERN_POLICY_STATIC to KERN_SUCCESS after the underlying kernel RPC. Therefore a raw Mach result, an internal trace, or a lower-level client can expose this code even when a caller using the public wrapper only observes success.
For diagnosis, treat a wrapper-level success as insufficient proof that a legacy policy change became effective. Inspect the policy actually in force on the target thread and the exact interface that produced the status.
What to check
- Record whether the result came from a public wrapper, a direct Mach RPC, a kernel extension, or diagnostic instrumentation.
- Identify the requested flavor and target thread. A retry with the same target and static state does not make the property mutable.
- Do not classify this automatically as a privilege problem.
KERN_PROTECTION_FAILUREandKERN_DENIEDdescribe different failure classes. - When the goal is ordinary application responsiveness, use the documented higher-level scheduling or QoS mechanism appropriate to the application instead of assuming that a legacy Mach-policy request can override a static policy.