linux.git/arch, branch v3.12.41

KVM: x86: SYSENTER emulation is broken

2015-04-27T18:25:29+00:00

commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.

SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
   still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
   legacy-mode.
4. There is some unneeded code.

Fix it.

Signed-off-by: Nadav Amit 
Signed-off-by: Paolo Bonzini 
[zhangzhiqiang: backport to 3.10:
 - adjust context
 - in 3.10 context "ctxt->eflags &= ~(EFLG_VM | EFLG_IF | EFLG_RF)" is replaced by
   "ctxt->eflags &= ~(EFLG_VM | EFLG_IF)" in upstream, which was changed by another commit.
 - After the above adjustments, becomes same to the original patch:
       https://github.com/torvalds/linux/commit/f3747379accba8e95d70cec0eae0582c8c182050
]
Signed-off-by: Zhiqiang Zhang 
Signed-off-by: Jiri Slaby

x86/reboot: Add ASRock Q1900DC-ITX mainboard reboot quirk

2015-04-22T06:58:40+00:00

commit 80313b3078fcd2ca51970880d90757f05879a193 upstream.

The ASRock Q1900DC-ITX mainboard (Baytrail-D) hangs randomly in
both BIOS and UEFI mode while rebooting unless reboot=pci is
used. Add a quirk to reboot via the pci method.

The problem is very intermittent and hard to debug, it might succeed
rebooting just fine 40 times in a row - but fails half a dozen times
the next day. It seems to be slightly less common in BIOS CSM mode
than native UEFI (with the CSM disabled), but it does happen in either
mode. Since I've started testing this patch in late january, rebooting
has been 100% reliable.

Most of the time it already hangs during POST, but occasionally it
might even make it through the bootloader and the kernel might even
start booting, but then hangs before the mode switch. The same symptoms
occur with grub-efi, gummiboot and grub-pc, just as well as (at least)
kernel 3.16-3.19 and 4.0-rc6 (I haven't tried older kernels than 3.16).
Upgrading to the most current mainboard firmware of the ASRock
Q1900DC-ITX, version 1.20, does not improve the situation.

( Searching the web seems to suggest that other Bay Trail-D mainboards
  might be affected as well. )
--
Signed-off-by: Stefan Lippers-Hollmann 
Cc: Matt Fleming 
Link: http://lkml.kernel.org/r/20150330224427.0fb58e42@mir
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

ARC: SA_SIGINFO ucontext regs off-by-one

2015-04-22T06:58:31+00:00

commit 6914e1e3f63caa829431160f0f7093292daef2d5 upstream.

The regfile provided to SA_SIGINFO signal handler as ucontext was off by
one due to pt_regs gutter cleanups in 2013.

Before handling signal, user pt_regs are copied onto user_regs_struct and copied
back later. Both structs are binary compatible. This was all fine until
commit 2fa919045b72 (ARC: pt_regs update #2) which removed the empty stack slot
at top of pt_regs (corresponding to first pad) and made the corresponding
fixup in struct user_regs_struct (the pad in there was moved out of
@scratch - not removed altogether as it is part of ptrace ABI)

 struct user_regs_struct {
+       long pad;
        struct {
-               long pad;
                long bta, lp_start, lp_end,....
        } scratch;
 ...
 }

This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
which is what this commit does.

This problem was hidden for 2 years, because both save/restore, despite
using wrong location, were using the same location. Only an interim
inspection (reproducer below) exposed the issue.

     void handle_segv(int signo, siginfo_t *info, void *context)
     {
 	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
               regs->scratch.r8, regs->scratch.r9);
     }

     int main()
     {
	struct sigaction sa;

	sa.sa_sigaction = handle_segv;
	sa.sa_flags = SA_SIGINFO;
	sigemptyset(&sa.sa_mask);
	sigaction(SIGSEGV, &sa, NULL);

	asm volatile(
	"mov	r7, 7	\n"
	"mov	r8, 8	\n"
	"mov	r9, 9	\n"
	"mov	r10, 10	\n"
	:::"r7","r8","r9","r10");

	*((unsigned int*)0x10) = 0;
     }

Fixes: 2fa919045b72ec892e "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
Signed-off-by: Vineet Gupta 
Signed-off-by: Jiri Slaby

x86/reboot: Add reboot quirk for Certec BPC600

2015-04-21T15:38:42+00:00

commit aadca6fa4068ad1f92c492bc8507b7ed350825a2 upstream.

Certec BPC600 needs reboot=pci to actually reboot.

Signed-off-by: Christian Gmeiner 
Cc: Matthew Garrett 
Cc: Li Aubrey 
Cc: Andrew Morton 
Cc: Dave Jones 
Cc: Fenghua Yu 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/1399446114-2147-1-git-send-email-christian.gmeiner@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

x86/reboot: Sort reboot DMI quirks by vendor

2015-04-21T15:34:46+00:00

commit e56e57f6613d5ed5c3127419341d1aa989a11971 upstream.

Grouping them by vendor should make it easier to spot duplicates.

Signed-off-by: Dave Jones 
Link: http://lkml.kernel.org/r/20131001203655.GA10719@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

x86/reboot: Remove the duplicate C6100 entry in the reboot quirks list

2015-04-21T15:20:58+00:00

commit b5eafc6f07c95e9f3dd047e72737449cb03c9956 upstream.

Two entries for the same system type were added, with two different vendor
names: 'Dell' and 'Dell, Inc.'.

Since a prefix match is being used by the DMI parsing code, we can eliminate
the latter as redundant.

Reported-by: "H. Peter Anvin" 
Signed-off-by: Masoud Sharbiani 
Cc: holt@sgi.com
Link: http://lkml.kernel.org/r/1380216643-4683-1-git-send-email-masoud.sharbiani@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

powerpc/pseries: Little endian fixes for post mobility device tree update

2015-04-21T14:30:02+00:00

commit f6ff04149637723261aa4738958b0098b929ee9e upstream.

We currently use the device tree update code in the kernel after resuming
from a suspend operation to re-sync the kernels view of the device tree with
that of the hypervisor. The code as it stands is not endian safe as it relies
on parsing buffers returned by RTAS calls that thusly contains data in big
endian format.

This patch annotates variables and structure members with __be types as well
as performing necessary byte swaps to cpu endian for data that needs to be
parsed.

Signed-off-by: Tyrel Datwyler 
Cc: Nathan Fontenot 
Cc: Cyril Bur 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby

arm64: Use the reserved TTBR0 if context switching to the init_mm

2015-04-21T14:30:01+00:00

commit e53f21bce4d35a93b23d8fa1a840860f6c74f59e upstream.

The idle_task_exit() function may call switch_mm() with next ==
&init_mm. On arm64, init_mm.pgd cannot be used for user mappings, so
this patch simply sets the reserved TTBR0.

Reported-by: Jon Medhurst (Tixy) 
Tested-by: Jon Medhurst (Tixy) 
Signed-off-by: Catalin Marinas 
Signed-off-by: Jiri Slaby

x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable()

2015-04-09T12:13:48+00:00

commit d97eb8966c91f2c9d05f0a22eb89ed5b76d966d1 upstream.

When an interrupt is migrated away from a cpu it will stay
in its vector_irq array until smp_irq_move_cleanup_interrupt
succeeded. The cfg->move_in_progress flag is cleared already
when the IPI was sent.

When the interrupt is destroyed after migration its 'struct
irq_desc' is freed and the vector_irq arrays are cleaned up.
But since cfg->move_in_progress is already 0 the references
at cpus before the last migration will not be cleared. So
this would leave a reference to an already destroyed irq
alive.

When the cpu is taken down at this point, the
check_irq_vectors_for_cpu_disable() function finds a valid irq
number in the vector_irq array, but gets NULL for its
descriptor and dereferences it, causing a kernel panic.

This has been observed on real systems at shutdown. Add a
check to check_irq_vectors_for_cpu_disable() for a valid
'struct irq_desc' to prevent this issue.

Signed-off-by: Joerg Roedel 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Jiang Liu 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: K. Y. Srinivasan 
Cc: Linus Torvalds 
Cc: Prarit Bhargava 
Cc: Rasmus Villemoes 
Cc: Yinghai Lu 
Cc: alnovak@suse.com
Cc: joro@8bytes.org
Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby

powerpc: Fix sys_call_table declaration to enable syscall tracing

2015-04-09T12:13:46+00:00

commit 1028ccf560b97adbf272381a61a67e17d44d1054 upstream.

Declaring sys_call_table as a pointer causes the compiler to generate
the wrong lookup code in arch_syscall_addr().

     :
        lis     r9,-16384
        rlwinm  r3,r3,2,0,29
  -     lwz     r11,30640(r9)
  -     lwzx    r3,r11,r3
  +     addi    r9,r9,30640
  +     lwzx    r3,r9,r3
        blr

The actual sys_call_table symbol, declared in assembler, is an
array. If we lie about that to the compiler we get the wrong code
generated, as above.

This definition seems only to be used by the syscall tracing code in
kernel/trace/trace_syscalls.c. With this patch I can successfully use
the syscall tracepoints:

  bash-3815  [002] ....   333.239082: sys_write -> 0x2
  bash-3815  [002] ....   333.239087: sys_dup2(oldfd: a, newfd: 1)
  bash-3815  [002] ....   333.239088: sys_dup2 -> 0x1
  bash-3815  [002] ....   333.239092: sys_fcntl(fd: a, cmd: 1, arg: 0)
  bash-3815  [002] ....   333.239093: sys_fcntl -> 0x1
  bash-3815  [002] ....   333.239094: sys_close(fd: a)
  bash-3815  [002] ....   333.239094: sys_close -> 0x0

Signed-off-by: Romeo Cane 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby