linux-stable.git/arch/arm64/kernel, branch linux-4.1.y

arm64: Disable unhandled signal log messages by default

2018-03-04T15:28:34+00:00

[ Upstream commit 5ee39a71fd89ab7240c5339d04161c44a8e03269 ]

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.

Cc: 
Signed-off-by: Michael Weiser 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: fpsimd: Prevent registers leaking from dead tasks

2018-01-17T17:55:24+00:00

[ Upstream commit 071b6d4a5d343046f253a5a8835d477d93992002 ]

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.

Cc: 
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: Sasha Levin

arm64: hw_breakpoint: fix watchpoint matching for tagged pointers

2018-01-17T17:55:16+00:00

[ Upstream commit 7dcd9dd8cebe9fa626af7e2358d03a37041a70fb ]

When we take a watchpoint exception, the address that triggered the
watchpoint is found in FAR_EL1. We compare it to the address of each
configured watchpoint to see which one was hit.

The configured watchpoint addresses are untagged, while the address in
FAR_EL1 will have an address tag if the data access was done using a
tagged address. The tag needs to be removed to compare the address to
the watchpoints.

Currently we don't remove it, and as a result can report the wrong
watchpoint as being hit (specifically, always either the highest TTBR0
watchpoint or lowest TTBR1 watchpoint). This patch removes the tag.

Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc:  # 3.12.x-
Acked-by: Mark Rutland 
Acked-by: Will Deacon 
Signed-off-by: Kristina Martsenko 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: ensure __dump_instr() checks addr_limit

2017-12-07T02:19:53+00:00

[ Upstream commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 ]

It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.

Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.

Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.

Fixes: 60ffc30d5652810d ("arm64: Exception handling")
Cc: stable@vger.kernel.org
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: Make sure SPsel is always set

2017-11-05T00:17:53+00:00

[ Upstream commit 5371513fb338fb9989c569dc071326d369d6ade8 ]

When the kernel is entered at EL2 on an ARMv8.0 system, we construct
the EL1 pstate and make sure this uses the the EL1 stack pointer
(we perform an exception return to EL1h).

But if the kernel is either entered at EL1 or stays at EL2 (because
we're on a VHE-capable system), we fail to set SPsel, and use whatever
stack selection the higher exception level has choosen for us.

Let's not take any chance, and make sure that SPsel is set to one
before we decide the mode we're going to run in.

Cc: 
Acked-by: Mark Rutland 
Signed-off-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: fpsimd: Prevent registers leaking across exec

2017-10-04T01:36:40+00:00

[ Upstream commit 096622104e14d8a1db4860bd557717067a0515d2 ]

There are some tricky dependencies between the different stages of
flushing the FPSIMD register state during exec, and these can race
with context switch in ways that can cause the old task's regs to
leak across.  In particular, a context switch during the memset() can
cause some of the task's old FPSIMD registers to reappear.

Disabling preemption for this small window would be no big deal for
performance: preemption is already disabled for similar scenarios
like updating the FPSIMD registers in sigreturn.

So, instead of rearranging things in ways that might swap existing
subtle bugs for new ones, this patch just disables preemption
around the FPSIMD state flushing so that races of this type can't
occur here.  This brings fpsimd_flush_thread() into line with other
code paths.

Cc: stable@vger.kernel.org
Fixes: 674c242c9323 ("arm64: flush FP/SIMD state correctly after execve()")
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Dave Martin 
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

arm64: armv8_deprecated: ensure extension of addr

2017-07-31T17:37:47+00:00

[ Upstream commit 55de49f9aa17b0b2b144dd2af587177b9aadf429 ]

Our compat swp emulation holds the compat user address in an unsigned
int, which it passes to __user_swpX_asm(). When a 32-bit value is passed
in a register, the upper 32 bits of the register are unknown, and we
must extend the value to 64 bits before we can use it as a base address.

This patch casts the address to unsigned long to ensure it has been
suitably extended, avoiding the potential issue, and silencing a related
warning from clang.

Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Cc:  # 3.19.x-
Acked-by: Will Deacon 
Signed-off-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64: entry: improve data abort handling of tagged pointers

2017-06-26T02:02:20+00:00

[ Upstream commit 276e93279a630657fff4b086ba14c95955912dfa ]

When handling a data abort from EL0, we currently zero the top byte of
the faulting address, as we assume the address is a TTBR0 address, which
may contain a non-zero address tag. However, the address may be a TTBR1
address, in which case we should not zero the top byte. This patch fixes
that. The effect is that the full TTBR1 address is passed to the task's
signal handler (or printed out in the kernel log).

When handling a data abort from EL1, we leave the faulting address
intact, as we assume it's either a TTBR1 address or a TTBR0 address with
tag 0x00. This is true as far as I'm aware, we don't seem to access a
tagged TTBR0 address anywhere in the kernel. Regardless, it's easy to
forget about address tags, and code added in the future may not always
remember to remove tags from addresses before accessing them. So add tag
handling to the EL1 data abort handler as well. This also makes it
consistent with the EL0 data abort handler.

Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Cc:  # 3.12.x-
Reviewed-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Kristina Martsenko 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64/ptrace: Reject attempts to set incomplete hardware breakpoint fields

2017-03-06T22:29:28+00:00

[ Upstream commit ad9e202aa1ce571b1d7fed969d06f66067f8a086 ]

We cannot preserve partial fields for hardware breakpoints, because
the values written by userspace to the hardware breakpoint
registers can't subsequently be recovered intact from the hardware.

So, just reject attempts to write incomplete fields with -EINVAL.

Cc:  # 3.7.x-
Fixes: 478fcb2cdb23 ("arm64: Debugging support")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

arm64/ptrace: Preserve previous registers for short regset write

2017-03-06T22:29:27+00:00

[ Upstream commit 9a17b876b573441bfb3387ad55d98bf7184daf9d ]

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Cc:  # 3.7.x-
Fixes: 478fcb2cdb23 ("arm64: Debugging support")
Signed-off-by: Dave Martin 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin