linux-stable.git/arch/arm64/kernel/syscall.c, branch v5.8

arm64: syscall: Expand the comment about ptrace and syscall(-1)

2020-07-16T10:41:58+00:00

If a task executes syscall(-1), we intercept this early and force x0 to
be -ENOSYS so that we don't need to distinguish this scenario from one
where the scno is -1 because a tracer wants to skip the system call
using ptrace. With the return value set, the return path is the same as
the skip case.

Although there is a one-line comment noting this in el0_svc_common(), it
misses out most of the detail. Expand the comment to describe a bit more
about what is going on.

Cc: Mark Rutland 
Cc: Keno Fischer 
Cc: Luis Machado 
Signed-off-by: Will Deacon

arm64: compat: Ensure upper 32 bits of x0 are zero on syscall return

2020-07-16T10:41:31+00:00

Although we zero the upper bits of x0 on entry to the kernel from an
AArch32 task, we do not clear them on the exception return path and can
therefore expose 64-bit sign extended syscall return values to userspace
via interfaces such as the 'perf_regs' ABI, which deal exclusively with
64-bit registers.

Explicitly clear the upper 32 bits of x0 on return from a compat system
call.

Cc: 
Cc: Mark Rutland 
Cc: Keno Fischer 
Cc: Luis Machado 
Signed-off-by: Will Deacon

arm64: ptrace: Consistently use pseudo-singlestep exceptions

2020-07-16T10:41:07+00:00

Although the arm64 single-step state machine can be fast-forwarded in
cases where we wish to generate a SIGTRAP without actually executing an
instruction, this has two major limitations outside of simply skipping
an instruction due to emulation.

1. Stepping out of a ptrace signal stop into a signal handler where
   SIGTRAP is blocked. Fast-forwarding the stepping state machine in
   this case will result in a forced SIGTRAP, with the handler reset to
   SIG_DFL.

2. The hardware implicitly fast-forwards the state machine when executing
   an SVC instruction for issuing a system call. This can interact badly
   with subsequent ptrace stops signalled during the execution of the
   system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt
   the stepping state by updating the PSTATE for the tracee.

Resolve both of these issues by injecting a pseudo-singlestep exception
on entry to a signal handler and also on return to userspace following a
system call.

Cc: 
Cc: Mark Rutland 
Tested-by: Luis Machado 
Reported-by: Keno Fischer 
Signed-off-by: Will Deacon

arm64: Basic Branch Target Identification support

2020-03-16T17:19:48+00:00

This patch adds the bare minimum required to expose the ARMv8.5
Branch Target Identification feature to userspace.

By itself, this does _not_ automatically enable BTI for any initial
executable pages mapped by execve().  This will come later, but for
now it should be possible to enable BTI manually on those pages by
using mprotect() from within the target process.

Other arches already using the generic mman.h are already using
0x10 for arch-specific prot flags, so we use that for PROT_BTI
here.

For consistency, signal handler entry points in BTI guarded pages
are required to be annotated as such, just like any other function.
This blocks a relatively minor attack vector, but comforming
userspace will have the annotations anyway, so we may as well
enforce them.

Signed-off-by: Mark Brown 
Signed-off-by: Dave Martin 
Reviewed-by: Catalin Marinas 
Signed-off-by: Catalin Marinas

arm64: entry: cleanup el0 svc handler naming

2020-01-17T13:22:14+00:00

For most of the exception entry code, _handler() is the first C
function called from the entry assembly in entry-common.c, and external
functions handling the bulk of the logic are called do_().

For consistency, apply this scheme to el0_svc_handler and
el0_svc_compat_handler, renaming them to do_el0_svc and
do_el0_svc_compat respectively.

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

Signed-off-by: Mark Rutland 
Reviewed-by: Anshuman Khandual 
Cc: Catalin Marinas 
Cc: James Morse 
Cc: Will Deacon 
Signed-off-by: Will Deacon

arm64: Remove asmlinkage from updated functions

2019-10-28T11:22:51+00:00

Now that the callers of these functions have moved into C, they no longer
need the asmlinkage annotation. Remove it.

Signed-off-by: James Morse 
Acked-by: Mark Rutland 
Signed-off-by: Catalin Marinas

arm64: errata: Add workaround for Cortex-A76 erratum #1463225

2019-05-23T10:38:10+00:00

Revisions of the Cortex-A76 CPU prior to r4p0 are affected by an erratum
that can prevent interrupts from being taken when single-stepping.

This patch implements a software workaround to prevent userspace from
effectively being able to disable interrupts.

Cc: 
Cc: Marc Zyngier 
Cc: Catalin Marinas 
Signed-off-by: Will Deacon

arm64: compat: Don't pull syscall number from regs in arm_compat_syscall

2019-01-04T14:18:01+00:00

The syscall number may have been changed by a tracer, so we should pass
the actual number in from the caller instead of pulling it from the
saved r7 value directly.

Cc: 
Cc: Pi-Hsun Shih 
Reviewed-by: Dave Martin 
Signed-off-by: Will Deacon

arm64: svc: Ensure hardirq tracing is updated before return

2018-07-30T16:43:39+00:00

We always run userspace with interrupts enabled, but with the recent
conversion of the syscall entry/exit code to C, we don't inform the
hardirq tracing code that interrupts are about to become enabled by
virtue of restoring the EL0 SPSR.

This patch ensures that trace_hardirqs_on() is called on the syscall
return path when we return to the assembly code with interrupts still
disabled.

Fixes: f37099b6992a ("arm64: convert syscall trace logic to C")
Reported-by: Julien Grall 
Signed-off-by: Will Deacon

arm64: implement syscall wrappers

2018-07-12T13:49:48+00:00

To minimize the risk of userspace-controlled values being used under
speculation, this patch adds pt_regs based syscall wrappers for arm64,
which pass the minimum set of required userspace values to syscall
implementations. For each syscall, a wrapper which takes a pt_regs
argument is automatically generated, and this extracts the arguments
before calling the "real" syscall implementation.

Each syscall has three functions generated:

* __do_sys_ is the "real" syscall implementation, with
  the expected prototype.

* __se_sys_ is the sign-extension/narrowing wrapper,
  inherited from common code. This takes a series of long parameters,
  casting each to the requisite types required by the "real" syscall
  implementation in __do_sys_.

  This wrapper *may* not be necessary on arm64 given the AAPCS rules on
  unused register bits, but it seemed safer to keep the wrapper for now.

* __arm64__sys_ takes a struct pt_regs pointer, and
  extracts *only* the relevant register values, passing these on to the
  __se_sys_ wrapper.

The syscall invocation code is updated to handle the calling convention
required by __arm64__sys_, and passes a single struct
pt_regs pointer.

The compiler can fold the syscall implementation and its wrappers, such
that the overhead of this approach is minimized.

Note that we play games with sys_ni_syscall(). It can't be defined with
SYSCALL_DEFINE0() because we must avoid the possibility of error
injection. Additionally, there are a couple of locations where we need
to call it from C code, and we don't (currently) have a
ksys_ni_syscall().  While it has no wrapper, passing in a redundant
pt_regs pointer is benign per the AAPCS.

When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is defines for
sys_ni_syscall(). Since we need to treat it differently for in-kernel
calls and the syscall tables, the prototype is defined as-required.

The wrappers are largely the same as their x86 counterparts, but
simplified as we don't have a variety of compat calling conventions that
require separate stubs. Unlike x86, we have some zero-argument compat
syscalls, and must define COMPAT_SYSCALL_DEFINE0() to ensure that these
are also given an __arm64_compat_sys_ prefix.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Reviewed-by: Catalin Marinas 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Will Deacon