linux-stable.git/arch/arm64/kernel, branch v3.16.78

arm64: compat: Allow single-byte watchpoints on all addresses

2019-11-22T15:57:08+00:00

commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream.

Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte
watchpoints on all addresses") changed the validation requirements for
hardware watchpoints on arch/arm/. Update our compat layer to implement
the same relaxation.

Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

jump_label: Rename JUMP_LABEL_{EN,DIS}ABLE to JUMP_LABEL_{JMP,NOP}

2019-05-22T22:15:03+00:00

commit 76b235c6bcb16062d663e2ee96db0b69f2e6bc14 upstream.

Since we've already stepped away from ENABLE is a JMP and DISABLE is a
NOP with the branch_default bits, and are going to make it even worse,
rename it to make it all clearer.

This way we don't mix multiple levels of logic attributes, but have a
plain 'physical' name for what the current instruction patching status
of a jump label is.

This is a first step in removing the naming confusion that has led to
a stream of avoidable bugs such as:

  a833581e372a ("x86, perf: Fix static_key bug in load_mm_cr4()")

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
[ Beefed up the changelog. ]
Signed-off-by: Ingo Molnar 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

arm64: Use get_signal() signal_setup_done()

2019-05-02T20:41:41+00:00

commit 00554fa4f80279db92f82c4f52c8ae72711f173e upstream.

Use the more generic functions get_signal() signal_setup_done()
for signal delivery.

Signed-off-by: Richard Weinberger 
[bwh: Backported to 3.16 as dependency of commit 35634ffa1751
 "signal: Always notice exiting tasks"]
Signed-off-by: Ben Hutchings

arm64: __show_regs: Only resolve kernel symbols when running at EL1

2018-06-16T21:22:21+00:00

commit a06f818a70de21b4b3b4186816094208fc7accf9 upstream.

__show_regs pretty prints PC and LR by attempting to map them to kernel
function names to improve the utility of crash reports. Unfortunately,
this mapping is applied even when the pt_regs corresponds to user mode,
resulting in a KASLR oracle.

Avoid this issue by only looking up the function symbols when the register
state indicates that we're actually running at EL1.

Reported-by: NCSC Security 
Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

arm64: Remove unimplemented syscall log message

2018-06-16T21:22:21+00:00

commit 1962682d2b2fbe6cfa995a85c53c069fadda473e upstream.

Stop printing a (ratelimited) kernel message for each instance of an
unimplemented syscall being called. Userland making an unimplemented
syscall is not necessarily misbehaviour and to be expected with a
current userland running on an older kernel. Also, the current message
looks scary to users but does not actually indicate a real problem nor
help them narrow down the cause. Just rely on sys_ni_syscall() to return
-ENOSYS.

Acked-by: Will Deacon 
Signed-off-by: Michael Weiser 
Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: Deleted code was slightly different]
Signed-off-by: Ben Hutchings

arm64: Disable unhandled signal log messages by default

2018-06-16T21:22:21+00:00

commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 upstream.

aarch64 unhandled signal kernel messages are very verbose, suggesting
them to be more of a debugging aid:

sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
0x92000046, in sigsegv[400000+71000]
CPU: 1 PID: 33 Comm: sigsegv Tainted: G        W        4.15.0-rc3+ #3
Hardware name: linux,dummy-virt (DT)
pstate: 60000000 (nZCv daif -PAN -UAO)
pc : 0x4003f4
lr : 0x4006bc
sp : 0000fffffe94a060
x29: 0000fffffe94a070 x28: 0000000000000000
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 00000000004001b0
x23: 0000000000486ac8 x22: 00000000004001c8
x21: 0000000000000000 x20: 0000000000400be8
x19: 0000000000400b30 x18: 0000000000484728
x17: 000000000865ffc8 x16: 000000000000270f
x15: 00000000000000b0 x14: 0000000000000002
x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 0008000020008008
x9 : 000000000000000f x8 : ffffffffffffffff
x7 : 0004000000000000 x6 : ffffffffffffffff
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
x1 : 000000000000000a x0 : 0000000000000000

Disable them by default, so they can be enabled using
/proc/sys/debug/exception-trace.

Signed-off-by: Michael Weiser 
Signed-off-by: Will Deacon 
Signed-off-by: Ben Hutchings

arm64: do not use print_symbol()

2018-06-16T21:22:21+00:00

commit 4ef7963843d3243260aa335dfb9cb2fede06aacf upstream.

print_symbol() is a very old API that has been obsoleted by %pS format
specifier in a normal printk() call.

Replace print_symbol() with a direct printk("%pS") call.

Link: http://lkml.kernel.org/r/20171211125025.2270-3-sergey.senozhatsky@gmail.com
To: Andrew Morton 
To: Russell King 
To: Catalin Marinas 
To: Mark Salter 
To: Tony Luck 
To: David Howells 
To: Yoshinori Sato 
To: Guan Xuetao 
To: Borislav Petkov 
To: Greg Kroah-Hartman 
To: Thomas Gleixner 
To: Peter Zijlstra 
To: Vineet Gupta 
To: Fengguang Wu 
Cc: Steven Rostedt 
Cc: Petr Mladek 
Cc: LKML 
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-am33-list@redhat.com
Cc: linux-sh@vger.kernel.org
Cc: linux-edac@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Sergey Senozhatsky 
[pmladek@suse.com: updated commit message]
Signed-off-by: Petr Mladek 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

arm64: traps: Don't print stack or raw PC/LR values in backtraces

2018-06-16T21:22:21+00:00

commit a25ffd3a6302a67814280274d8f1aa4ae2ea4b59 upstream.

Printing raw pointer values in backtraces has potential security
implications and are of questionable value anyway.

This patch follows x86's lead and removes the "Exception stack:" dump
from kernel backtraces, as well as converting PC/LR values to symbols
such as "sysrq_handle_crash+0x20/0x30".

Tested-by: Laura Abbott 
Signed-off-by: Will Deacon 
[bwh: Backported to 3.16:
 - Deleted code in dump_mem() and dump_backtrace_entry() is a bit different
 - Leave dump_backtrace() unchanged, since it doesn't use dump_mem()]
Signed-off-by: Ben Hutchings

arm64: remove __die()'s stack dump

2018-06-16T21:22:20+00:00

commit c5bc503cbeee8586395aa541d2b53c69c3dd6930 upstream.

Our __die() implementation tries to dump the stack memory, in addition
to a backtrace, which is problematic.

For contemporary 16K stacks, this can be a lot of data, which can take a
long time to dump, and can push other useful context out of the kernel's
printk ringbuffer (and/or a user's scrollback buffer on an attached
console).

Additionally, the code implicitly assumes that the SP is on the task's
stack, and tries to dump everything between the SP and the highest task
stack address. When the SP points at an IRQ stack (or is corrupted),
this makes the kernel attempt to dump vast amounts of VA space. With
vmap'd stacks, this may result in erroneous accesses to peripherals.

This patch removes the memory dump, leaving us to rely on the backtrace,
and other means of dumping stack memory such as kdump.

Signed-off-by: Mark Rutland 
Reviewed-by: Will Deacon 
Tested-by: Laura Abbott 
Cc: Ard Biesheuvel 
Cc: Catalin Marinas 
Cc: James Morse 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

arm64: fpsimd: Prevent registers leaking from dead tasks

2018-03-03T15:51:45+00:00

commit 071b6d4a5d343046f253a5a8835d477d93992002 upstream.

Currently, loading of a task's fpsimd state into the CPU registers
is skipped if that task's state is already present in the registers
of that CPU.

However, the code relies on the struct fpsimd_state * (and by
extension struct task_struct *) to unambiguously identify a task.

There is a particular case in which this doesn't work reliably:
when a task exits, its task_struct may be recycled to describe a
new task.

Consider the following scenario:

 1) Task P loads its fpsimd state onto cpu C.
        per_cpu(fpsimd_last_state, C) := P;
        P->thread.fpsimd_state.cpu := C;

 2) Task X is scheduled onto C and loads its fpsimd state on C.
        per_cpu(fpsimd_last_state, C) := X;
        X->thread.fpsimd_state.cpu := C;

 3) X exits, causing X's task_struct to be freed.

 4) P forks a new child T, which obtains X's recycled task_struct.
	T == X.
	T->thread.fpsimd_state.cpu == C (inherited from P).

 5) T is scheduled on C.
	T's fpsimd state is not loaded, because
	per_cpu(fpsimd_last_state, C) == T (== X) &&
	T->thread.fpsimd_state.cpu == C.

        (This is the check performed by fpsimd_thread_switch().)

So, T gets X's registers because the last registers loaded onto C
were those of X, in (2).

This patch fixes the problem by ensuring that the sched-in check
fails in (5): fpsimd_flush_task_state(T) is called when T is
forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
This relies on the fact that T is not schedulable until after
copy_thread() completes.

Once T's fpsimd state has been loaded on some CPU C there may still
be other cpus D for which per_cpu(fpsimd_last_state, D) ==
&X->thread.fpsimd_state.  But D is necessarily != C in this case,
and the check in (5) must fail.

An alternative fix would be to do refcounting on task_struct.  This
would result in each CPU holding a reference to the last task whose
fpsimd state was loaded there.  It's not clear whether this is
preferable, and it involves higher overhead than the fix proposed
in this patch.  It would also move all the task_struct freeing
work into the context switch critical section, or otherwise some
deferred cleanup mechanism would need to be introduced, neither of
which seems obviously justified.

Fixes: 005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
Signed-off-by: Dave Martin 
Reviewed-by: Ard Biesheuvel 
[will: word-smithed the comment so it makes more sense]
Signed-off-by: Will Deacon 
Signed-off-by: Ben Hutchings