linux-stable.git/arch/arc, branch v4.1.45

ARC: Re-enable MMU upon Machine Check exception

2017-10-04T11:43:02+00:00

[ Upstream commit 1ee55a8f7f6b7ca4c0c59e0b4b4e3584a085c2d3 ]

I recently came upon a scenario where I would get a double fault
machine check exception tiriggered by a kernel module.
However the ensuing crash stacktrace (ksym lookup) was not working
correctly.

Turns out that machine check auto-disables MMU while modules are allocated
in kernel vaddr spapce.

This patch re-enables the MMU before start printing the stacktrace
making stacktracing of modules work upon a fatal exception.

Cc: stable@kernel.org
Signed-off-by: Jose Abreu 
Reviewed-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta 
[vgupta: moved code into low level handler to avoid in 2 places]

Signed-off-by: Sasha Levin

mm: larger stack guard gap, between vmas

2017-06-28T22:57:15+00:00

[ Upstream commit 1be7107fbe18eed3e319a6c3e83c78254b693acb ]

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov 
Original-patch-by: Michal Hocko 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Tested-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup

2017-03-06T22:31:13+00:00

[ Upstream commit a524c218bc94c705886a0e0fedeee45d1931da32 ]

Reported-by: Jo-Philipp Wich 
Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-kernel@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

ARC: [arcompact] handle unaligned access delay slot corner case

2017-03-06T22:31:12+00:00

[ Upstream commit 9aed02feae57bf7a40cb04ea0e3017cb7a998db4 ]

After emulating an unaligned access in delay slot of a branch, we
pretend as the delay slot never happened - so return back to actual
branch target (or next PC if branch was not taken).

Curently we did this by handling STATUS32.DE, we also need to clear the
BTA.T bit, which is disregarded when returning from original misaligned
exception, but could cause weirdness if it took the interrupt return
path (in case interrupt was acive too)

One ARC700 customer ran into this when enabling unaligned access fixup
for kernel mode accesses as well

Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: uaccess: get_user to zero out dest in cause of fault

2016-10-03T01:13:30+00:00

[ Upstream commit 05d9d0b96e53c52a113fd783c0c97c830c8dc7af ]

Al reported potential issue with ARC get_user() as it wasn't clearing
out destination pointer in case of fault due to bad address etc.

Verified using following

| {
|  	u32 bogus1 = 0xdeadbeef;
|	u64 bogus2 = 0xdead;
|	int rc1, rc2;
|
|  	pr_info("Orig values %x %llx\n", bogus1, bogus2);
|	rc1 = get_user(bogus1, (u32 __user *)0x40000000);
|	rc2 = get_user(bogus2, (u64 __user *)0x50000000);
|	pr_info("access %d %d, new values %x %llx\n",
|		rc1, rc2, bogus1, bogus2);
| }

| [ARCLinux]# insmod /mnt/kernel-module/qtn.ko
| Orig values deadbeef dead
| access -14 -14, new values 0 0

Reported-by: Al Viro 
Cc: Linus Torvalds 
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Al Viro 
Signed-off-by: Sasha Levin

Revert "ARC: mm: don't loose PTE_SPECIAL in pte_modify()"

2016-09-15T22:55:55+00:00

This reverts commit 93c0b008e79f11430ce07b6271b37671051d4298.

Signed-off-by: Sasha Levin

ARC: export __udivdi3 for modules

2016-08-31T23:21:09+00:00

[ Upstream commit c57653dc94d0db7bf63067433ceaa97bdcd0a312 ]

Some module using div_u64() was failing to link because the libgcc 64-bit
divide assist routine was not being exported for modules

Reported-by: avinashp@quantenna.com
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: Support syscall ABI v4

2016-08-31T23:21:09+00:00

[ Upstream commit 840c054fd0efb048df6fceb0c46385ec5b66dfe6 ]

The syscall ABI includes the gcc functional calling ABI since a syscall
implies userland caller and kernel callee.

The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in
even-odd register pairs, (potentially punching reg holes when passing such
values as args). This was partly driven by the fact that the double-word
LDD/STD instructions in ARCv2 expect the register alignment and thus gcc
forcing this avoids extra MOV at the cost of a few unused register (which we
have plenty anyways).

This however was rejected as part of upstreaming gcc port to HS. So the new
ABI v4 doesn't enforce the even-odd reg restriction.

Do note that for ARCompact ISA builds v3 and v4 are practically the same in
terms of gcc code generation.

In terms of change management, we infer the new ABI if gcc 6.x onwards
is used for building the kernel.

This also needs a stable backport to enable older kernels to work with
new tools/user-space

Cc: 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

ARC: use correct offset in pt_regs for saving/restoring user mode r25

2016-08-31T23:21:09+00:00

[ Upstream commit 86147e3cfa5e118b61e78f4f0bf29e920dcbd477 ]

User mode callee regs are explicitly collected before signal delivery or
breakpoint trap. r25 is special for kernel as it serves as task pointer,
so user mode value is clobbered very early. It is saved in pt_regs where
generally only scratch (aka caller saved) regs are saved.

The code to access the corresponding pt_regs location had a subtle bug as
it was using load/store with scaling of offset, whereas the offset was already
byte wise correct. So fix this by replacing LD.AS with a standard LD

Cc: 
Signed-off-by: Liav Rehana 
Reviewed-by: Alexey Brodkin 
[vgupta: rewrote title and commit log]
Signed-off-by: Vineet Gupta 

Signed-off-by: Sasha Levin

ARCv2: STAR 9000808988: signals involving Delay Slot

2016-08-31T23:21:09+00:00

[ Upstream commit 0d7b8855a05c099a5c65a8d49a1e604198021f56 ]

Reported by Anton as LTP:munmap01 failing with Illegal Instruction
Exception.

   --------------------->8--------------------------------------
   mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000
   munmap(0x200d2000, 24576)               = 0
   --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000}
   ---
   potentially unexpected fatal signal 4.
   Path: /munmap01
   CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8
   task: 9f1a8000 ti: 9f154000 task.ti: 9f154000

   [ECR   ]: 0x00020100 => Illegal Insn
   [EFA   ]: 0x0001354c
   [BLINK ]: 0x200515d4
   [ERET  ]: 0x1354c
       @off 0x1354c in [/munmap01]
       VMA: 0x00010000 to 0x00018000
   [STAT32]: 0x800802c0
   ...
   --------------------->8--------------------------------------

The issue was
1. munmap01 accessed unmapped memory (on purpose) with signal handler
   installed for SIGSEGV

2. The faulting instruction happened to be in Delay Slot
   00011864 :
      11908:	bl.d       13284 
      1190c:	stb        r16,[r2]

3. kernel sets up the reg file for signal handler and correctly clears
   the DE bit in pt_regs->status32 placeholder

4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2,
   and it over-writes the above with orig/stale value of status32

5. After RTIE, userspace signal handler executes a non branch
   instruction with DE bit set, triggering Illegal Instruction Exception.

Reported-by: Anton Kolesov 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin