linux.git/arch/powerpc/kernel/syscall.c, branch v7.3-rc2

Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2026-08-18T22:00:56+00:00

Pull generic entry code updates from Thomas Gleixner:

 - Make syscall user dispatching configurable

   Not all architectures can makes use of syscall user dispatching.
   Allow them to disable the feature completely.

 - Consolidate stack randomization for the generic entry code and the
   architectures using it.

   Stack randomization on syscall entry was sprinkled throughout the
   architecture specific low level entry code and in some cases at the
   wrong points, e.g. before establishing state, which violates the
   non-instrumentable constraints of that code.

   Clean this up by integrating stack randomization into the generic
   entry code helpers so that it is invoked at the earliest possible
   point right after establishing state and converting all generic entry
   code using architecture over.

 - Clean up the syscall number handling in the generic entry code. It
   works correctly for architectures which have a separate return value
   storage in pt_regs, but fails to distinguish the case where user
   space handed in -1 as syscall number from the case where the entry
   code rejects it by returning -1 to the callers. Aside of that the
   return value functionality of those interfaces is not really
   intuitive.

   Fix this by separating the decision to reject a syscall (user
   dispatch, ptrace, seccomp ...) from the potential modification of the
   syscall number through these mechanisms.

   This solves most of the problems for architectures which do not have
   a separate return value storage in pt_regs except for the case where
   a tracepoint has a BPF script or a probe attached which overwrite
   both the syscall number and the return value. But that's a problem
   which cannot be solved in the generic code, that only can be
   addressed by separating the storage model in the affected
   architectures.

* tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
  entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
  entry: Make return type of syscall_trace_enter() bool
  entry: Rework trace_syscall_enter()
  entry: Rework syscall_audit_enter()
  syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
  entry: Fix seccomp bypass after ptrace with TSYNC
  x86/entry: Simplify the syscall number logic
  x86/entry: Get rid of the sys_ni_syscall() indirection
  x86/entry: Make syscall functions static
  ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()
  seccomp, treewide: Rename and convert __secure_computing() to return boolean
  entry: Use syscall number instead of rereading it
  entry: Remove syscall_enter_from_user_mode()
  x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack()
  s390/syscall: Use enter_from_user_mode_randomize_stack()
  riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack()
  entry: Provide [syscall_]enter_from_user_mode_randomize_stack()
  randomize_kstack: Provide add_random_kstack_offset_irqsoff()
  ...

powerpc/syscall: Fix syscall skip handling for seccomp and ptrace

2026-08-03T08:39:14+00:00

After enabling GENERIC_ENTRY on PowerPC, syscall_enter_from_user_mode()
returns -1 as a sentinel to signal that seccomp or ptrace has intercepted
the syscall and already set a return value via syscall_set_return_value().
system_call_exception() was not handling this sentinel, and since -1UL
is >= NR_syscalls, the code fell into the out-of-range path and returned
-ENOSYS, overwriting the errno already placed in regs->gpr[3].

The naive fix of checking r0 == -1L before the NR_syscalls bounds check
is ambiguous: a user legitimately calling syscall(-1) also produces r0 ==
-1L, and a tracer intercepting such a call would have its injected return
value silently discarded.

Fix this by introducing a thread flag that is set whenever
syscall_set_return_value() explicitly updates the return value. In
system_call_exception(), check and clear this flag before dispatching
the syscall, and return the preset value directly when it is present.
This ensures that an explicitly supplied return value always suppresses
syscall execution, regardless of the syscall number.

This handles all seccomp actions correctly:

  - SECCOMP_RET_ERRNO, SECCOMP_RET_TRACE (no tracer), SECCOMP_RET_USER_NOTIF:
    all call syscall_set_return_value(), flag is set, injected value returned.
  - SECCOMP_RET_TRAP, SECCOMP_RET_KILL: call syscall_rollback() and deliver
    a signal; flag is not set, but the process is dying so the return value
    is irrelevant.

The fix covers both ppc32 and ppc64 with no #ifdefs.

Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature")
Reported-by: Michal Suchánek 
Closes: https://lore.kernel.org/all/ajpp-_XnbF3UTM_E@kunlun.suse.cz/
Tested-by: Michal Suchánek 
Reviewed-by: Michal Suchánek 
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260731081521.1852133-1-mkchauras@gmail.com

entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution

2026-07-20T18:38:40+00:00

The return values of syscall_enter_from_user_mode[_work]() are
non-intuitive. Both functions return the syscall number which should be
invoked by the architecture specific syscall entry code. The returned
number can be:

  - the unmodified syscall number which was handed in by the caller

  - a modified syscall number (ptrace, seccomp, trace/probe/bpf)

That has an additional twist. If the return value is -1L then the caller is
not allowed to modify the return value as that indicates that the modifying
entity requests to abort the syscall and set the return value already. That
can obviously not be differentiated from a syscall which handed in -1 as
syscall number.

The most trivial way to deal with that is:

    set_return_value(regs, -ENOSYS);
    nr = syscall_enter_from_user_mode(regs, nr);
    if (valid(nr))
    	handle_syscall(regs, nr);

That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not
preset the return value, so when user space hands in -1 and there is
nothing setting the return value in the entry work code, then the syscall
is skipped but the return value is whatever random data has been in the
return value register.

Change the return values of syscall_enter_from_user_mode[_work]() to
boolean and return false, when either ptrace or seccomp request to skip the
syscall. If they return true, update the syscall number as it might have
been changed.

That results in slightly different behaviour of the architectures versus
tracing.

If the syscall tracepoint has probe/BPF attached, those might set the
syscall number to -1 and also set the return value. PowerPC and S390 will
then overwrite that value with -ENOSYS. The other architectures will just
ignore it like any other invalid syscall and use the modified one.

Originally-by: Michal Suchánek 
Signed-off-by: Thomas Gleixner 
Tested-by: Michal Suchánek 
Link: https://patch.msgid.link/20260712141346.772209074@kernel.org

powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack()

2026-07-12T10:38:01+00:00

syscall_enter_from_user_mode_randomize_stack() replaces
syscall_enter_from_user_mode() and the subsequent invocation of
add_random_kstack_offset().

The advantage is that it applies the stack randomization right after
enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var()
as that code is invoked with interrupts disabled.

No functional change.

Signed-off-by: Thomas Gleixner 
Tested-by: Mukesh Kumar Chaurasiya (IBM) 
Reviewed-by: Radu Rendec 
Reviewed-by: Jinjie Ruan 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) 
Link: https://patch.msgid.link/20260707190253.918861529@kernel.org

powerpc: Move stack randomization after syscall_enter_from_user_mode()

2026-07-12T10:38:00+00:00

add_random_kstack_offset() is invoked before syscall_enter_from_user_mode()
establishes state. That's wrong because add_random_kstack_offset() calls
into instrumentable code.

Move it after syscall_enter_from_user_mode() to ensure that state is
correctly established.

Signed-off-by: Thomas Gleixner 
Tested-by: Mukesh Kumar Chaurasiya (IBM) 
Reviewed-by: Shrikanth Hegde 
Reviewed-by: Radu Rendec 
Reviewed-by: Jinjie Ruan 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Mukesh Kumar Chaurasiya (IBM) 
Link: https://patch.msgid.link/20260707190253.718191130@kernel.org

powerpc: Enable GENERIC_ENTRY feature

2026-05-20T01:27:14+00:00

Enable the generic IRQ entry/exit infrastructure on PowerPC by selecting
GENERIC_ENTRY and integrating the architecture-specific interrupt and
syscall handlers with the generic entry/exit APIs.

This change replaces PowerPC’s local interrupt entry/exit handling with
calls to the generic irqentry_* helpers, aligning the architecture with
the common kernel entry model. The macros that define interrupt, async,
and NMI handlers are updated to use irqentry_enter()/irqentry_exit()
and irqentry_nmi_enter()/irqentry_nmi_exit() where applicable also
convert the PowerPC syscall entry and exit paths to use the generic
entry/exit framework and integrating with the common syscall handling
routines.

Key updates include:
 - The architecture now selects GENERIC_ENTRY in Kconfig.
 - Replace interrupt_enter/exit_prepare() with arch_interrupt_* helpers.
 - Integrate irqentry_enter()/exit() in standard and async interrupt paths.
 - Integrate irqentry_nmi_enter()/exit() in NMI handlers.
 - Remove redundant irq_enter()/irq_exit() calls now handled generically.
 - Use irqentry_exit_cond_resched() for preemption checks.
 - interrupt.c and syscall.c are simplified to delegate context
   management and user exit handling to the generic entry path.
 - The new pt_regs field `exit_flags` introduced earlier is now used
   to carry per-syscall exit state flags (e.g. _TIF_RESTOREALL).
 - Remove unused code.

This change establishes the necessary wiring for PowerPC to use the
generic IRQ entry/exit framework while maintaining existing semantics.
This aligns PowerPC with the common entry code used by other
architectures and reduces duplicated logic around syscall tracing,
context tracking, and signal handling.

The performance benchmarks from perf bench basic syscall are below:

perf bench syscall usec/op (-ve is improvement)

| Syscall | Base        | test        | change % |
| ------- | ----------- | ----------- | -------- |
| basic   | 0.093543    | 0.093023    | -0.56    |
| execve  | 446.557781  | 450.107172  | +0.79    |
| fork    | 1142.204391 | 1156.377214 | +1.24    |
| getpgid | 0.097666    | 0.092677    | -5.11    |

perf bench syscall ops/sec (+ve is improvement)

| Syscall | Base     | New      | change % |
| ------- | -------- | -------- | -------- |
| basic   | 10690548 | 10750140 | +0.56    |
| execve  | 2239     | 2221     | -0.80    |
| fork    | 875      | 864      | -1.26    |
| getpgid | 10239026 | 10790324 | +5.38    |

IPI latency benchmark (-ve is improvement)

| Metric         | Base (ns)     | New (ns)      | % Change |
| -------------- | ------------- | ------------- | -------- |
| Dry run        | 583136.56     | 584136.35     | 0.17%    |
| Self IPI       | 4167393.42    | 4149093.90    | -0.44%   |
| Normal IPI     | 61769347.82   | 61753728.39   | -0.03%   |
| Broadcast IPI  | 2235584825.02 | 2227521401.45 | -0.36%   |
| Broadcast lock | 2164964433.31 | 2125658641.76 | -1.82%   |

Thats very close to performance earlier with arch specific handling.

Signed-off-by: Mukesh Kumar Chaurasiya 
Tested-by: Samir M 
Tested-by: David Gow 
Tested-by: Venkat Rao Bagalkote 
Reviewed-by: Shrikanth Hegde 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260427122742.210074-8-mkchauras@gmail.com

powerpc: rename arch_irq_disabled_regs

2026-05-20T01:27:13+00:00

Rename arch_irq_disabled_regs() to regs_irqs_disabled() to align with the
naming used in the generic irqentry framework. This makes the function
available for use both in the PowerPC architecture code and in the
common entry/exit paths shared with other architectures.

This is a preparatory change for enabling the generic irqentry framework
on PowerPC.

Signed-off-by: Mukesh Kumar Chaurasiya 
Tested-by: Samir M 
Tested-by: David Gow 
Tested-by: Venkat Rao Bagalkote 
Reviewed-by: Shrikanth Hegde 
Reviewed-by: Jinjie Ruan 
Signed-off-by: Madhavan Srinivasan 
Link: https://patch.msgid.link/20260427122742.210074-2-mkchauras@gmail.com

randomize_kstack: Unify random source across arches

2026-03-25T04:12:03+00:00

Previously different architectures were using random sources of
differing strength and cost to decide the random kstack offset. A number
of architectures (loongarch, powerpc, s390, x86) were using their
timestamp counter, at whatever the frequency happened to be. Other
arches (arm64, riscv) were using entropy from the crng via
get_random_u16().

There have been concerns that in some cases the timestamp counters may
be too weak, because they can be easily guessed or influenced by user
space. And get_random_u16() has been shown to be too costly for the
level of protection kstack offset randomization provides.

So let's use a common, architecture-agnostic source of entropy; a
per-cpu prng, seeded at boot-time from the crng. This has a few
benefits:

  - We can remove choose_random_kstack_offset(); That was only there to
    try to make the timestamp counter value a bit harder to influence
    from user space [*].

  - The architecture code is simplified. All it has to do now is call
    add_random_kstack_offset() in the syscall path.

  - The strength of the randomness can be reasoned about independently
    of the architecture.

  - Arches previously using get_random_u16() now have much faster
    syscall paths, see below results.

[*] Additionally, this gets rid of some redundant work on s390 and x86.
Before this patch, those architectures called
choose_random_kstack_offset() under arch_exit_to_user_mode_prepare(),
which is also called for exception returns to userspace which were *not*
syscalls (e.g. regular interrupts). Getting rid of
choose_random_kstack_offset() avoids a small amount of redundant work
for the non-syscall cases.

In some configurations, add_random_kstack_offset() will now call
instrumentable code, so for a couple of arches, I have moved the call a
bit later to the first point where instrumentation is allowed. This
doesn't impact the efficacy of the mechanism.

There have been some claims that a prng may be less strong than the
timestamp counter if not regularly reseeded. But the prng has a period
of about 2^113. So as long as the prng state remains secret, it should
not be possible to guess. If the prng state can be accessed, we have
bigger problems.

Additionally, we are only consuming 6 bits to randomize the stack, so
there are only 64 possible random offsets. I assert that it would be
trivial for an attacker to brute force by repeating their attack and
waiting for the random stack offset to be the desired one. The prng
approach seems entirely proportional to this level of protection.

Performance data are provided below. The baseline is v6.18 with rndstack
on for each respective arch. (I)/(R) indicate statistically significant
improvement/regression. arm64 platform is AWS Graviton3 (m7g.metal).
x86_64 platform is AWS Sapphire Rapids (m7i.24xlarge):

+-----------------+--------------+---------------+---------------+
| Benchmark       | Result Class |  per-cpu-prng |  per-cpu-prng |
|                 |              | arm64 (metal) |   x86_64 (VM) |
+=================+==============+===============+===============+
| syscall/getpid  | mean (ns)    |    (I) -9.50% |   (I) -17.65% |
|                 | p99 (ns)     |   (I) -59.24% |   (I) -24.41% |
|                 | p99.9 (ns)   |   (I) -59.52% |   (I) -28.52% |
+-----------------+--------------+---------------+---------------+
| syscall/getppid | mean (ns)    |    (I) -9.52% |   (I) -19.24% |
|                 | p99 (ns)     |   (I) -59.25% |   (I) -25.03% |
|                 | p99.9 (ns)   |   (I) -59.50% |   (I) -28.17% |
+-----------------+--------------+---------------+---------------+
| syscall/invalid | mean (ns)    |   (I) -10.31% |   (I) -18.56% |
|                 | p99 (ns)     |   (I) -60.79% |   (I) -20.06% |
|                 | p99.9 (ns)   |   (I) -61.04% |   (I) -25.04% |
+-----------------+--------------+---------------+---------------+

I tested an earlier version of this change on x86 bare metal and it
showed a smaller but still significant improvement. The bare metal
system wasn't available this time around so testing was done in a VM
instance. I'm guessing the cost of rdtsc is higher for VMs.

Acked-by: Mark Rutland 
Signed-off-by: Ryan Roberts 
Link: https://patch.msgid.link/20260303150840.3789438-3-ryan.roberts@arm.com
Signed-off-by: Kees Cook

treewide: context_tracking: Rename CONTEXT_* into CT_STATE_*

2024-07-29T02:03:10+00:00

Context tracking state related symbols currently use a mix of the
CONTEXT_ (e.g. CONTEXT_KERNEL) and CT_SATE_ (e.g. CT_STATE_MASK) prefixes.

Clean up the naming and make the ctx_state enum use the CT_STATE_ prefix.

Suggested-by: Frederic Weisbecker 
Signed-off-by: Valentin Schneider 
Acked-by: Frederic Weisbecker 
Acked-by: Thomas Gleixner 
Signed-off-by: Neeraj Upadhyay

powerpc: Use user_mode() macro when possible

2024-02-22T10:55:33+00:00

There is a nice macro to check user mode.

Use it instead of open coding anding with MSR_PR to increase
readability and avoid having to comment what that anding is for.

Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/fbf74887dcf1f1ba9e1680fc3247cbb581b00662.1708078228.git.christophe.leroy@csgroup.eu