linux.git/arch/s390/kernel/entry.S, branch v5.10.258

s390/syscalls: Add spectre boundary for syscall dispatch table

2026-04-18T08:31:17+00:00

[ Upstream commit 48b8814e25d073dd84daf990a879a820bad2bcbd ]

The s390 syscall number is directly controlled by userspace, but does
not have an array_index_nospec() boundary to prevent access past the
syscall function pointer tables.

Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Alexander Gordeev 
Cc: Christian Borntraeger 
Cc: Sven Schnelle 
Cc: Arnd Bergmann 
Fixes: 56e62a737028 ("s390: convert to generic entry")
Cc: stable@kernel.org
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: Vasily Gorbik 
Link: https://lore.kernel.org/r/2026032404-sterling-swoosh-43e6@gregkh
Signed-off-by: Vasily Gorbik 
[ gor: 5.10 backport. In 5.10, commit 56e62a737028 ("s390: convert to
  generic entry") has not been applied — syscall dispatch is in
  assembly (entry.S), not in C (syscall.c). The equivalent to
  array_index_nospec() is implemented using the same clgr/slbgr/ngr.

  SVC 0 path: the user-controlled syscall number in r1 is clamped via
  a single unsigned compare (clgr) followed by slbgr/ngr. The original
  cghi/jnl bounds check branch is replaced — the clamp handles both
  cases: in-bounds values pass through, out-of-bounds values are zeroed
  (producing the same r8=0 dispatch to table[0] as the original branch).

  SVC 1-255 path: syscall number from the 8-bit instruction immediate
  is always in bounds. ]
Reviewed-by: Sven Schnelle 
Reviewed-by: Ilya Leoshkevich 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

s390/entry: align system call table on 8 bytes

2024-04-13T10:59:36+00:00

commit 378ca2d2ad410a1cd5690d06b46c5e2297f4c8c0 upstream.

Align system call table on 8 bytes. With sys_call_table entry size
of 8 bytes that eliminates the possibility of a system call pointer
crossing cache line boundary.

Cc: stable@kernel.org
Suggested-by: Ulrich Weigand 
Reviewed-by: Alexander Gordeev 
Signed-off-by: Sumanth Korikkar 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

s390: add support for TIF_NOTIFY_SIGNAL

2023-01-04T10:39:19+00:00

[ Upstream commit 75309018a24ddfb930c51bad8f4070b9bc2c923b ]

Wire up TIF_NOTIFY_SIGNAL handling for s390.

Cc: linux-s390@vger.kernel.org
Acked-by: Heiko Carstens 
Acked-by: Sven Schnelle 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/mcck: fix calculation of SIE critical section size

2021-06-23T12:42:51+00:00

commit 5bcbe3285fb614c49db6b238253f7daff7e66312 upstream.

The size of SIE critical section is calculated wrongly
as result of a missed subtraction in commit 0b0ed657fe00
("s390: remove critical section cleanup from entry.S")

Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Cc: 
Signed-off-by: Alexander Gordeev 
Reviewed-by: Christian Borntraeger 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

s390/entry: save the caller of psw_idle

2021-04-28T11:40:02+00:00

[ Upstream commit a994eddb947ea9ebb7b14d9a1267001699f0a136 ]

Currently psw_idle does not allocate a stack frame and does not
save its r14 and r15 into the save area. Even though this is valid from
call ABI point of view, because psw_idle does not make any calls
explicitly, in reality psw_idle is an entry point for controlled
transition into serving interrupts. So, in practice, psw_idle stack
frame is analyzed during stack unwinding. Depending on build options
that r14 slot in the save area of psw_idle might either contain a value
saved by previous sibling call or complete garbage.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs
 ([task    0000038000003dd8] 0x0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

So, to make a stacktrace nicer and actually point for the real caller of
psw_idle in this frequently occurring case, make psw_idle save its r14.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs
 ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

Reviewed-by: Sven Schnelle 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390: always clear kernel stack backchain before calling functions

2021-01-06T13:56:55+00:00

[ Upstream commit 9365965db0c7ca7fc81eee27c21d8522d7102c32 ]

Clear the kernel stack backchain before potentially calling the
lockdep trace_hardirqs_off/on functions. Without this walking the
kernel backchain, e.g. during a panic, might stop too early.

Signed-off-by: Heiko Carstens 
Signed-off-by: Sasha Levin

s390/idle: fix accounting with machine checks

2020-12-30T10:54:08+00:00

commit 454efcf82ea17d7efeb86ebaa20775a21ec87d27 upstream.

When a machine check interrupt is triggered during idle, the code
is using the async timer/clock for idle time calculation. It should use
the machine check enter timer/clock which is passed to the macro.

Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Cc:  # 5.8
Reviewed-by: Heiko Carstens 
Signed-off-by: Sven Schnelle 
Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

s390/idle: add missing mt_cycles calculation

2020-12-30T10:54:08+00:00

commit e259b3fafa7de362b04ecd86e7fa9a9e9273e5fb upstream.

During removal of the critical section cleanup the calculation
of mt_cycles during idle was removed. This causes invalid
accounting on systems with SMT enabled.

Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Cc:  # 5.8
Reviewed-by: Heiko Carstens 
Signed-off-by: Sven Schnelle 
Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

s390: fix irq state tracing

2020-12-02T17:17:50+00:00

With commit 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs
tracing") common code calls arch_cpu_idle() with a lockdep state that
tells irqs are on.

This doesn't work very well for s390: psw_idle() will enable interrupts
to wait for an interrupt. As soon as an interrupt occurs the interrupt
handler will verify if the old context was psw_idle(). If that is the
case the interrupt enablement bits in the old program status word will
be cleared.

A subsequent test in both the external as well as the io interrupt
handler checks if in the old context interrupts were enabled. Due to
the above patching of the old program status word it is assumed the
old context had interrupts disabled, and therefore a call to
TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in
turn makes lockdep incorrectly "think" that interrupts are enabled
within the interrupt handler.

Fix this by unconditionally calling TRACE_IRQS_OFF when entering
interrupt handlers. Also call unconditionally TRACE_IRQS_ON when
leaving interrupts handlers.

This leaves the special psw_idle() case, which now returns with
interrupts disabled, but has an "irqs on" lockdep state. So callers of
psw_idle() must adjust the state on their own, if required. This is
currently only __udelay_disabled().

Fixes: 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing")
Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Heiko Carstens

s390: fix fpu restore in entry.S

2020-11-23T10:52:13+00:00

We need to disable interrupts in load_fpu_regs(). Otherwise an
interrupt might come in after the registers are loaded, but before
CIF_FPU is cleared in load_fpu_regs(). When the interrupt returns,
CIF_FPU will be cleared and the registers will never be restored.

The entry.S code usually saves the interrupt state in __SF_EMPTY on the
stack when disabling/restoring interrupts. sie64a however saves the pointer
to the sie control block in __SF_SIE_CONTROL, which references the same
location.  This is non-obvious to the reader. To avoid thrashing the sie
control block pointer in load_fpu_regs(), move the __SIE_* offsets eight
bytes after __SF_EMPTY on the stack.

Cc:  # 5.8
Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Reported-by: Pierre Morel 
Signed-off-by: Sven Schnelle 
Acked-by: Christian Borntraeger 
Reviewed-by: Heiko Carstens 
Signed-off-by: Heiko Carstens