linux.git/arch, branch v3.10.94

arm64: Fix compat register mappings

2015-12-09T18:40:10+00:00

commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_ and LR_ backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat__ macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.

Signed-off-by: Robin Murphy 
Acked-by: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

x86/cpu: Fix SMAP check in PVOPS environments

2015-12-09T18:40:08+00:00

commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 upstream.

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

Signed-off-by: Andrew Cooper 
Reviewed-by: David Vrabel 
Tested-by: Rusty Russell 
Cc: Rusty Russell 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: 
Cc: Xen-devel 
Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/cpu: Call verify_cpu() after having entered long mode too

2015-12-09T18:40:08+00:00

commit 04633df0c43d710e5f696b06539c100898678235 upstream.

When we get loaded by a 64-bit bootloader, kernel entry point is
startup_64 in head_64.S. We don't trust any and all bootloaders because
some will fiddle with CPU configuration so we go ahead and massage each
CPU into sanity again.

For example, some dell BIOSes have this XD disable feature which set
IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
for other OSes but Linux sure doesn't need it.

A similar thing is present in the Surface 3 firmware - see
https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
only on the BSP:

  # rdmsr -a 0x1a0
  400850089
  850089
  850089
  850089

I know, right?!

There's not even an off switch in there.

So fix all those cases by sanitizing the 64-bit entry point too. For
that, make verify_cpu() callable in 64-bit mode also.

Requested-and-debugged-by: "H. Peter Anvin" 
Reported-and-tested-by: Bastien Nocera 
Signed-off-by: Borislav Petkov 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/setup: Fix low identity map for >= 2GB kernel range

2015-12-09T18:40:08+00:00

commit 68accac392d859d24adcf1be3a90e41f978bd54c upstream.

The commit f5f3497cad8c extended the low identity mapping. However, if
the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory
split), the normal memory mapping is overwritten by the low identity
mapping causing a crash. To avoid overwritting, limit the low identity
map to cover only memory before kernel range (PAGE_OFFSET).

Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel range
Signed-off-by: Krzysztof Mazur 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Laszlo Ersek 
Cc: Matt Fleming 
Cc: Paolo Bonzini 
Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@podlesie.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/setup: Extend low identity map to cover whole kernel range

2015-12-09T18:40:08+00:00

commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

On 32-bit systems, the initial_page_table is reused by
efi_call_phys_prolog as an identity map to call
SetVirtualAddressMap.  efi_call_phys_prolog takes care of
converting the current CPU's GDT to a physical address too.

For PAE kernels the identity mapping is achieved by aliasing the
first PDPE for the kernel memory mapping into the first PDPE
of initial_page_table.  This makes the EFI stub's trick "just work".

However, for non-PAE kernels there is no guarantee that the identity
mapping in the initial_page_table extends as far as the GDT; in this
case, accesses to the GDT will cause a page fault (which quickly becomes
a triple fault).  Fix this by copying the kernel mappings from
swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
identity mapping.

For some reason, this is only reproducible with QEMU's dynamic translation
mode, and not for example with KVM.  However, even under KVM one can clearly
see that the page table is bogus:

    $ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
    $ gdb
    (gdb) target remote localhost:1234
    (gdb) hb *0x02858f6f
    Hardware assisted breakpoint 1 at 0x2858f6f
    (gdb) c
    Continuing.

    Breakpoint 1, 0x02858f6f in ?? ()
    (gdb) monitor info registers
    ...
    GDT=     0724e000 000000ff
    IDT=     fffbb000 000007ff
    CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
    ...

The page directory is sane:

    (gdb) x/4wx 0x32b7000
    0x32b7000:	0x03398063	0x03399063	0x0339a063	0x0339b063
    (gdb) x/4wx 0x3398000
    0x3398000:	0x00000163	0x00001163	0x00002163	0x00003163
    (gdb) x/4wx 0x3399000
    0x3399000:	0x00400003	0x00401003	0x00402003	0x00403003

but our particular page directory entry is empty:

    (gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
    0x32b7070:	0x00000000

[ It appears that you can skate past this issue if you don't receive
  any interrupts while the bogus GDT pointer is loaded, or if you avoid
  reloading the segment registers in general.

  Andy Lutomirski provides some additional insight:

   "AFAICT it's entirely permissible for the GDTR and/or LDT
    descriptor to point to unmapped memory.  Any attempt to use them
    (segment loads, interrupts, IRET, etc) will try to access that memory
    as if the access came from CPL 0 and, if the access fails, will
    generate a valid page fault with CR2 pointing into the GDT or
    LDT."

  Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
  calls, not in the epilog/prolog calls") interrupts were disabled
  around the prolog and epilog calls, and the functional GDT was
  re-installed before interrupts were re-enabled.

  Which explains why no one has hit this issue until now. ]

Signed-off-by: Paolo Bonzini 
Reported-by: Laszlo Ersek 
Cc: 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Andy Lutomirski 
Signed-off-by: Matt Fleming 
[ Updated changelog. ]
Signed-off-by: Greg Kroah-Hartman

ARM: orion: Fix DSA platform device after mvmdio conversion

2015-12-09T18:40:08+00:00

commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream.

DSA expects the host_dev pointer to be the device structure associated
with the MDIO bus controller driver. First commit breaking that was
c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO
driver"), and then, it got completely under the radar for a while.

Reported-by: Frans van de Wiel 
Fixes: c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
Signed-off-by: Florian Fainelli 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Greg Kroah-Hartman

ARM: 8427/1: dma-mapping: add support for offset parameter in dma_mmap()

2015-12-09T18:40:07+00:00

commit 7e31210349e9e03a9a4dff31ab5f2bc83e8e84f5 upstream.

IOMMU-based dma_mmap() implementation lacked proper support for offset
parameter used in mmap call (it always assumed that mapping starts from
offset zero). This patch adds support for offset parameter to IOMMU-based
implementation.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8426/1: dma-mapping: add missing range check in dma_mmap()

2015-12-09T18:40:07+00:00

commit 371f0f085f629fc0f66695f572373ca4445a67ad upstream.

dma_mmap() function in IOMMU-based dma-mapping implementation lacked
a check for valid range of mmap parameters (offset and buffer size), what
might have caused access beyond the allocated buffer. This patch fixes
this issue.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

xen: fix backport of previous kexec patch

2015-11-09T18:12:59+00:00

Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream

Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support
kexec/kdump in HVM guests by doing a soft reset" has been added to the
4.2-stable tree" needed to correct the CONFIG variable, as
CONFIG_KEXEC_CORE only showed up in 4.3.

Reported-by: David Vrabel 
Reported-by: Luis Henriques 
Signed-off-by: Greg Kroah-Hartman

Revert "ARM64: unwind: Fix PC calculation"

2015-11-09T18:12:58+00:00

commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream.

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman