linux-stable.git/arch/arm/kernel, branch linux-5.17.y

signal: Deliver SIGTRAP on perf event asynchronously if blocked

2022-06-09T08:25:41+00:00

[ Upstream commit 78ed93d72ded679e3caf0758357209887bda885f ]

With SIGTRAP on perf events, we have encountered termination of
processes due to user space attempting to block delivery of SIGTRAP.
Consider this case:

    
    ...
    sigset_t s;
    sigemptyset(&s);
    sigaddset(&s, SIGTRAP | );
    sigprocmask(SIG_BLOCK, &s, ...);
    ...
    

When the perf event triggers, while SIGTRAP is blocked, force_sig_perf()
will force the signal, but revert back to the default handler, thus
terminating the task.

This makes sense for error conditions, but not so much for explicitly
requested monitoring. However, the expectation is still that signals
generated by perf events are synchronous, which will no longer be the
case if the signal is blocked and delivered later.

To give user space the ability to clearly distinguish synchronous from
asynchronous signals, introduce siginfo_t::si_perf_flags and
TRAP_PERF_FLAG_ASYNC (opted for flags in case more binary information is
required in future).

The resolution to the problem is then to (a) no longer force the signal
(avoiding the terminations), but (b) tell user space via si_perf_flags
if the signal was synchronous or not, so that such signals can be
handled differently (e.g. let user space decide to ignore or consider
the data imprecise).

The alternative of making the kernel ignore SIGTRAP on perf events if
the signal is blocked may work for some usecases, but likely causes
issues in others that then have to revert back to interception of
sigprocmask() (which we want to avoid). [ A concrete example: when using
breakpoint perf events to track data-flow, in a region of code where
signals are blocked, data-flow can no longer be tracked accurately.
When a relevant asynchronous signal is received after unblocking the
signal, the data-flow tracking logic needs to know its state is
imprecise. ]

Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events")
Reported-by: Dmitry Vyukov 
Signed-off-by: Marco Elver 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Geert Uytterhoeven 
Tested-by: Dmitry Vyukov 
Link: https://lore.kernel.org/r/20220404111204.935357-1-elver@google.com
Signed-off-by: Sasha Levin

ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2

2022-05-25T07:59:10+00:00

[ Upstream commit 3cfb3019979666bdf33a1010147363cf05e0f17b ]

In Thumb2, 'b . + 4' produces a branch instruction that uses a narrow
encoding, and so it does not jump to the following instruction as
expected. So use W(b) instead.

Fixes: 6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()

2022-05-25T07:59:01+00:00

[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
Hardware name: ARM-Versatile Express
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x98/0xb0)
[] (dump_stack) from [] (print_address_description.constprop.0+0x58/0x4bc)
[] (print_address_description.constprop.0) from [] (kasan_report+0x154/0x170)
[] (kasan_report) from [] (unwind_frame+0x508/0x870)
[] (unwind_frame) from [] (__save_stack_trace+0x110/0x134)
[] (__save_stack_trace) from [] (stack_trace_save+0x8c/0xb4)
[] (stack_trace_save) from [] (kasan_set_track+0x38/0x60)
[] (kasan_set_track) from [] (kasan_set_free_info+0x20/0x2c)
[] (kasan_set_free_info) from [] (__kasan_slab_free+0xec/0x120)
[] (__kasan_slab_free) from [] (kmem_cache_free+0x7c/0x334)
[] (kmem_cache_free) from [] (rcu_core+0x390/0xccc)
[] (rcu_core) from [] (__do_softirq+0x180/0x518)
[] (__do_softirq) from [] (irq_exit+0x9c/0xe0)
[] (irq_exit) from [] (__handle_domain_irq+0xb0/0x110)
[] (__handle_domain_irq) from [] (gic_handle_irq+0xa0/0xb8)
[] (gic_handle_irq) from [] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[] (__irq_svc) from [] (unwind_frame+0x0/0x870)
[] (unwind_frame) from [<00000000>] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c35ddff
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun 
Reported-by: He Ying 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Sasha Levin

uaccess: fix type mismatch warnings from access_ok()

2022-04-08T11:58:44+00:00

[ Upstream commit 23fc539e81295b14b50c6ccc5baeb4f3d59d822d ]

On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.

Fix the ones that I found either through my own test builds or
that were reported by the 0-day bot.

Reported-by: kernel test robot 
Reviewed-by: Christoph Hellwig 
Acked-by: Dinh Nguyen 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Sasha Levin

ARM: ftrace: avoid redundant loads or clobbering IP

2022-04-08T11:58:43+00:00

[ Upstream commit d11967870815b5ab89843980e35aab616c97c463 ]

Tweak the ftrace return paths to avoid redundant loads of SP, as well as
unnecessary clobbering of IP.

This also fixes the inconsistency of using MOV to perform a function
return, which is sub-optimal on recent micro-architectures but more
importantly, does not perform an interworking return, unlike compiler
generated function returns in Thumb2 builds.

Let's fix this by popping PC from the stack like most ordinary code
does.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Steven Rostedt (Google) 
Signed-off-by: Sasha Levin

ARM: fix Thumb2 regression with Spectre BHB

2022-03-11T19:40:08+00:00

When building for Thumb2, the vectors make use of a local label. Sadly,
the Spectre BHB code also uses a local label with the same number which
results in the Thumb2 reference pointing at the wrong place. Fix this
by changing the number used for the Spectre BHB local label.

Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Tested-by: Nathan Chancellor 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: Linus Torvalds

ARM: fix build error when BPF_SYSCALL is disabled

2022-03-08T20:53:05+00:00

It was missing a semicolon.

Signed-off-by: Emmanuel Gil Peyrot 
Reviewed-by: Nathan Chancellor 
Fixes: 25875aa71dfe ("ARM: include unprivileged BPF status in Spectre V2 reporting").
Signed-off-by: Linus Torvalds

Merge tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm

2022-03-08T17:08:06+00:00

Pull ARM spectre fixes from Russell King:
 "ARM Spectre BHB mitigations.

  These patches add Spectre BHB migitations for the following Arm CPUs
  to the 32-bit ARM kernels:
   - Cortex A15
   - Cortex A57
   - Cortex A72
   - Cortex A73
   - Cortex A75
   - Brahma B15
  for CVE-2022-23960"

* tag 'for-linus-bhb' of git://git.armlinux.org.uk/~rmk/linux-arm:
  ARM: include unprivileged BPF status in Spectre V2 reporting
  ARM: Spectre-BHB workaround
  ARM: use LOADADDR() to get load address of sections
  ARM: early traps initialisation
  ARM: report Spectre v2 status through sysfs

ARM: include unprivileged BPF status in Spectre V2 reporting

2022-03-08T14:46:08+00:00

The mitigations for Spectre-BHB are only applied when an exception
is taken, but when unprivileged BPF is enabled, userspace can
load BPF programs that can be used to exploit the problem.

When unprivileged BPF is enabled, report the vulnerable status via
the spectre_v2 sysfs file.

Signed-off-by: Russell King (Oracle)

ARM: Spectre-BHB workaround

2022-03-05T10:42:07+00:00

Workaround the Spectre BHB issues for Cortex-A15, Cortex-A57,
Cortex-A72, Cortex-A73 and Cortex-A75. We also include Brahma B15 as
well to be safe, which is affected by Spectre V2 in the same ways as
Cortex-A15.

Reviewed-by: Catalin Marinas 
Signed-off-by: Russell King (Oracle)