Skip to content
GitLab
  1. Dec 25, 2015
    • Rob Gardner's avatar
      sparc64: fix FP corruption in user copy functions · a7c5724b
      Rob Gardner authored 
      

Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.

Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.

The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.

The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.

This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.

n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address.  This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.

Signed-off-by: default avatarRob Gardner <rob.gardner@oracle.com>
Signed-off-by: default avatarDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7c5724b
    • Rob Gardner's avatar
      sparc64: Perf should save/restore fault info · 83352694
      Rob Gardner authored 
      

There have been several reports of random processes being killed with
a bus error or segfault during userspace stack walking in perf.  One
of the root causes of this problem is an asynchronous modification to
thread_info fault_address and fault_code, which stems from a perf
counter interrupt arriving during kernel processing of a "benign"
fault, such as a TSB miss. Since perf_callchain_user() invokes
copy_from_user() to read user stacks, a fault is not only possible,
but probable. Validity checks on the stack address merely cover up the
problem and reduce its frequency.

The solution here is to save and restore fault_address and fault_code
in perf_callchain_user() so that the benign fault handler is not
disturbed by a perf interrupt.

Signed-off-by: default avatarRob Gardner <rob.gardner@oracle.com>
Signed-off-by: default avatarDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83352694
    • Rob Gardner's avatar
      sparc64: Ensure perf can access user stacks · 3f74306a
      Rob Gardner authored 
      

When an interrupt (such as a perf counter interrupt) is delivered
while executing in user space, the trap entry code puts ASI_AIUS in
%asi so that copy_from_user() and copy_to_user() will access the
correct memory. But if a perf counter interrupt is delivered while the
cpu is already executing in kernel space, then the trap entry code
will put ASI_P in %asi, and this will prevent copy_from_user() from
reading any useful stack data in either of the perf_callchain_user_X
functions, and thus no user callgraph data will be collected for this
sample period. An additional problem is that a fault is guaranteed
to occur, and though it will be silently covered up, it wastes time
and could perturb state.

In perf_callchain_user(), we ensure that %asi contains ASI_AIUS
because we know for a fact that the subsequent calls to
copy_from_user() are intended to read the user's stack.

[ Use get_fs()/set_fs() -DaveM ]

Signed-off-by: default avatarRob Gardner <rob.gardner@oracle.com>
Signed-off-by: default avatarDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f74306a
    • Rob Gardner's avatar
      sparc64: Don't set %pil in rtrap_nmi too early · 1ca04a4c
      Rob Gardner authored 
      Commit 28a1f533

 delays setting %pil to avoid potential
hardirq stack overflow in the common rtrap_irq path.
Setting %pil also needs to be delayed in the rtrap_nmi
path for the same reason.

Signed-off-by: default avatarRob Gardner <rob.gardner@oracle.com>
Signed-off-by: default avatarDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ca04a4c
    • Khalid Aziz's avatar
      sparc64: Add ADI capability to cpu capabilities · 82924e54
      Khalid Aziz authored 
      

Add ADI (Application Data Integrity) capability to cpu capabilities list.
ADI capability allows virtual addresses to be encoded with a tag in
bits 63-60. This tag serves as an access control key for the regions
of virtual address with ADI enabled and a key set on them. Hypervisor
encodes this capability as "adp" in "hwcap-list" property in machine
description.

Signed-off-by: default avatarKhalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      82924e54
    • Aya Mahfouz's avatar
      tty: serial: constify sunhv_ops structs · 01fd3c27
      Aya Mahfouz authored 
      

Constifies sunhv_ops structures in tty's serial
driver since they are not modified after their
initialization.

Detected and found using Coccinelle.

Suggested-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: default avatarAya Mahfouz <mahfouz.saif.elyazal@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      01fd3c27
  3. Dec 24, 2015
  5. Dec 18, 2015
  7. Dec 17, 2015
  9. Dec 16, 2015