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

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: kernel: Save and restore addr_limit on exception entry

2016-08-14T15:28:21+00:00

commit e19a6ee2460bdd0d0055a6029383422773f9999a upstream.

If we take an exception while at EL1, the exception handler inherits
the original context's addr_limit value. To be consistent always reset
addr_limit and PSTATE.UAO on (re-)entry to EL1. This prevents accidental
re-use of the original context's addr_limit.

Based on a similar patch for arm from Russell King.

Acked-by: Will Deacon 
Reviewed-by: Mark Rutland 
Signed-off-by: James Morse 
Signed-off-by: Will Deacon 
[ backport to stop perf misusing inherited addr_limit.
  Removed code interacting with UAO and the irqstack ]
Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822
Signed-off-by: James Morse 
Cc:  #4.1
Signed-off-by: Sasha Levin

arm64: entry: fix context tracking for el0_sp_pc

2015-07-21T17:10:03+00:00

commit 46b0567c851cf85d6ba6f23eef385ec9111d09bc upstream.

Commit 6c81fe7925cc4c42 ("arm64: enable context tracking") did not
update el0_sp_pc to use ct_user_exit, but this appears to have been
unintentional. In commit 6ab6463aeb5fbc75 ("arm64: adjust el0_sync so
that a function can be called") we made x0 available, and in the return
to userspace we call ct_user_enter in the kernel_exit macro.

Due to this, we currently don't correctly inform RCU of the user->kernel
transition, and may erroneously account for time spent in the kernel as
if we were in an extended quiescent state when CONFIG_CONTEXT_TRACKING
is enabled.

As we do record the kernel->user transition, a userspace application
making accesses from an unaligned stack pointer can demonstrate the
imbalance, provoking the following warning:

------------[ cut here ]------------
WARNING: CPU: 2 PID: 3660 at kernel/context_tracking.c:75 context_tracking_enter+0xd8/0xe4()
Modules linked in:
CPU: 2 PID: 3660 Comm: a.out Not tainted 4.1.0-rc7+ #8
Hardware name: ARM Juno development board (r0) (DT)
Call trace:
[] dump_backtrace+0x0/0x124
[] show_stack+0x10/0x1c
[] dump_stack+0x84/0xc8
[] warn_slowpath_common+0x98/0xd0
[] warn_slowpath_null+0x14/0x20
[] context_tracking_enter+0xd4/0xe4
[] preempt_schedule_irq+0xd4/0x114
[] el1_preempt+0x4/0x28
[] exit_files+0x38/0x4c
[] do_exit+0x430/0x978
[] do_group_exit+0x40/0xd4
[] get_signal+0x23c/0x4f4
[] do_signal+0x1ac/0x518
[] do_notify_resume+0x5c/0x68
---[ end trace 963c192600337066 ]---

This patch adds the missing ct_user_exit to the el0_sp_pc entry path,
correcting the context tracking for this case.

Signed-off-by: Mark Rutland 
Acked-by: Will Deacon 
Fixes: 6c81fe7925cc ("arm64: enable context tracking")
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: errata: add workaround for cortex-a53 erratum #845719

2015-04-01T09:24:31+00:00

When running a compat (AArch32) userspace on Cortex-A53, a load at EL0
from a virtual address that matches the bottom 32 bits of the virtual
address used by a recent load at (AArch64) EL1 might return incorrect
data.

This patch works around the issue by writing to the contextidr_el1
register on the exception return path when returning to a 32-bit task.
This workaround is patched in at runtime based on the MIDR value of the
processor.

Reviewed-by: Marc Zyngier 
Tested-by: Mark Rutland 
Signed-off-by: Will Deacon

arm64: Implement the compat_sys_call_table in C

2015-01-27T09:38:07+00:00

Unlike the sys_call_table[], the compat one was implemented in sys32.S
making it impossible to notice discrepancies between the number of
compat syscalls and the __NR_compat_syscalls macro, the latter having to
be defined in asm/unistd.h as including asm/unistd32.h would cause
conflicts on __NR_* definitions. With this patch, incorrect
__NR_compat_syscalls values will result in a build-time error.

Signed-off-by: Catalin Marinas 
Suggested-by: Mark Rutland 
Acked-by: Mark Rutland

arm64: move to ESR_ELx macros

2015-01-15T12:24:15+00:00

Now that we have common ESR_ELx_* macros, move the core arm64 code over
to them.

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Reviewed-by: Christoffer Dall 
Cc: Marc Zyngier 
Cc: Peter Maydell 
Cc: Will Deacon

arm64: ptrace: allow tracer to skip a system call

2014-11-28T10:24:13+00:00

If tracer modifies a syscall number to -1, this traced system call should
be skipped with a return value specified in x0.
This patch implements this semantics.

Please note:
* syscall entry tracing and syscall exit tracing (ftrace tracepoint and
  audit) are always executed, if enabled, even when skipping a system call
  (that is, -1).
  In this way, we can avoid a potential bug where audit_syscall_entry()
  might be called without audit_syscall_exit() at the previous system call
  being called, that would cause OOPs in audit_syscall_entry().

Signed-off-by: AKASHI Takahiro 
[will: fixed up conflict with blr rework]
Signed-off-by: Will Deacon

arm64: Treat handle_arch_irq as a function pointer

2014-11-25T15:56:44+00:00

handle_arch_irq isn't actually text, it's just a function pointer.
It doesn't need to be stored in the text section and doing so
causes problesm if we ever want to make the kernel text read only.
Declare handle_arch_irq as a proper function pointer stored in
the data section.

Reviewed-by: Kees Cook 
Reviewed-by: Mark Rutland 
Acked-by: Ard Biesheuvel 
Tested-by: Mark Rutland 
Tested-by: Kees Cook 
Signed-off-by: Laura Abbott 
Signed-off-by: Will Deacon

arm64: entry: use ldp/stp instead of push/pop when saving/restoring regs

2014-11-14T10:42:21+00:00

The push/pop instructions can be suboptimal when saving/restoring large
amounts of data to/from the stack, for example on entry/exit from the
kernel. This is because:

  (1) They act on descending addresses (i.e. the newly decremented sp),
      which may defeat some hardware prefetchers

  (2) They introduce an implicit dependency between each instruction, as
      the sp has to be updated in order to resolve the address of the
      next access.

This patch removes the push/pop instructions from our kernel entry/exit
macros in favour of ldp/stp plus offset.

Signed-off-by: Will Deacon

arm64: entry: avoid writing lr explicitly for constructing return paths

2014-11-14T10:42:15+00:00

Using an explicit adr instruction to set the link register to point at
ret_fast_syscall/ret_to_user can defeat branch and return stack predictors.

Instead, use the standard calling instructions (bl, blr) and have an
unconditional branch as the following instruction.

Signed-off-by: Will Deacon