linux-toradex.git/arch, branch toradex_4.19.y

Merge remote-tracking branch 'remotes/origin/linux-4.19.y'

2019-01-08T06:02:41+00:00

Signed-off-by: Luka Pivk

ARM: dts: imx7: add DMA properties for ECSPI

2019-01-07T12:26:39+00:00

Allow to use DMA for SPI by adding the appropriate DMA properites
to the ecspi nodes.

Signed-off-by: Stefan Agner

ARM: dts: imx6ul: add DMA properties for ECSPI

2019-01-07T12:24:37+00:00

Allow to use DMA for SPI by adding the appropriate DMA properites
to the ecspi nodes.

Signed-off-by: Stefan Agner

ARM: imx: don't build ssi-fiq if not required

2019-01-03T14:24:35+00:00

The symbols provided by ssi-fiq are used in sound/soc/fsl/imx-pcm-fiq.c
only. Build ssi-fiq.o/ssi-fiq-ksym.o only if SND_SOC_IMX_PCM_FIQ is
enabled.

Signed-off-by: Stefan Agner

mm: make the __PAGETABLE_PxD_FOLDED defines non-empty

2018-12-29T12:37:57+00:00

[ Upstream commit a8874e7e8a8896f2b6c641f4b8e2473eafd35204 ]

Change the currently empty defines for __PAGETABLE_PMD_FOLDED,
__PAGETABLE_PUD_FOLDED and __PAGETABLE_P4D_FOLDED to return 1.
This makes it possible to use __is_defined() to test if the
preprocessor define exists.

Acked-by: Kirill A. Shutemov 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Sasha Levin

x86/intel_rdt: Ensure a CPU remains online for the region's pseudo-locking sequence

2018-12-29T12:37:57+00:00

commit 80b71c340f17705ec145911b9a193ea781811b16 upstream.

The user triggers the creation of a pseudo-locked region when writing
the requested schemata to the schemata resctrl file. The pseudo-locking
of a region is required to be done on a CPU that is associated with the
cache on which the pseudo-locked region will reside. In order to run the
locking code on a specific CPU, the needed CPU has to be selected and
ensured to remain online during the entire locking sequence.

At this time, the cpu_hotplug_lock is not taken during the pseudo-lock
region creation and it is thus possible for a CPU to be selected to run
the pseudo-locking code and then that CPU to go offline before the
thread is able to run on it.

Fix this by ensuring that the cpu_hotplug_lock is taken while the CPU on
which code has to run needs to be controlled. Since the cpu_hotplug_lock
is always taken before rdtgroup_mutex the lock order is maintained.

Fixes: e0bdfe8e36f3 ("x86/intel_rdt: Support creation/removal of pseudo-locked region")
Signed-off-by: Reinette Chatre 
Signed-off-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: gavin.hindman@intel.com
Cc: jithu.joseph@intel.com
Cc: stable 
Cc: x86-ml 
Link: https://lkml.kernel.org/r/b7b17432a80f95a1fa21a1698ba643014f58ad31.1544476425.git.reinette.chatre@intel.com
Signed-off-by: Greg Kroah-Hartman

x86/vdso: Pass --eh-frame-hdr to the linker

2018-12-29T12:37:57+00:00

commit cd01544a268ad8ee5b1dfe42c4393f1095f86879 upstream.

Commit

  379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")

accidentally broke unwinding from userspace, because ld would strip the
.eh_frame sections when linking.

Originally, the compiler would implicitly add --eh-frame-hdr when
invoking the linker, but when this Makefile was converted from invoking
ld via the compiler, to invoking it directly (like vmlinux does),
the flag was missed. (The EH_FRAME section is important for the VDSO
shared libraries, but not for vmlinux.)

Fix the problem by explicitly specifying --eh-frame-hdr, which restores
parity with the old method.

See relevant bug reports for additional info:

  https://bugzilla.kernel.org/show_bug.cgi?id=201741
  https://bugzilla.redhat.com/show_bug.cgi?id=1659295

Fixes: 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
Reported-by: Florian Weimer 
Reported-by: Carlos O'Donell 
Reported-by: "H. J. Lu" 
Signed-off-by: Alistair Strachan 
Signed-off-by: Borislav Petkov 
Tested-by: Laura Abbott 
Cc: Andy Lutomirski 
Cc: Carlos O'Donell 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Joel Fernandes 
Cc: kernel-team@android.com
Cc: Laura Abbott 
Cc: stable 
Cc: Thomas Gleixner 
Cc: X86 ML 
Link: https://lkml.kernel.org/r/20181214223637.35954-1-astrachan@google.com
Signed-off-by: Greg Kroah-Hartman

x86/mm: Fix decoy address handling vs 32-bit builds

2018-12-29T12:37:57+00:00

commit 51c3fbd89d7554caa3290837604309f8d8669d99 upstream.

A decoy address is used by set_mce_nospec() to update the cache attributes
for a page that may contain poison (multi-bit ECC error) while attempting
to minimize the possibility of triggering a speculative access to that
page.

When reserve_memtype() is handling a decoy address it needs to convert it
to its real physical alias. The conversion, AND'ing with __PHYSICAL_MASK,
is broken for a 32-bit physical mask and reserve_memtype() is passed the
last physical page. Gert reports triggering the:

    BUG_ON(start >= end);

...assertion when running a 32-bit non-PAE build on a platform that has
a driver resource at the top of physical memory:

    BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

Given that the decoy address scheme is only targeted at 64-bit builds and
assumes that the top of physical address space is free for use as a decoy
address range, simply bypass address sanitization in the 32-bit case.

Lastly, there was no need to crash the system when this failure occurred,
and no need to crash future systems if the assumptions of decoy addresses
are ever violated. Change the BUG_ON() to a WARN() with an error return.

Fixes: 510ee090abc3 ("x86/mm/pat: Prepare {reserve, free}_memtype() for...")
Reported-by: Gert Robben 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Tested-by: Gert Robben 
Cc: stable@vger.kernel.org
Cc: Andy Shevchenko 
Cc: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: platform-driver-x86@vger.kernel.org
Cc: 
Link: https://lkml.kernel.org/r/154454337985.789277.12133288391664677775.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Greg Kroah-Hartman

x86/mtrr: Don't copy uninitialized gentry fields back to userspace

2018-12-29T12:37:57+00:00

commit 32043fa065b51e0b1433e48d118821c71b5cd65d upstream.

Currently the copy_to_user of data in the gentry struct is copying
uninitiaized data in field _pad from the stack to userspace.

Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).

Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")

Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit ioctls")
Signed-off-by: Colin Ian King 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Tyler Hicks 
Cc: security@kernel.org
Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman

KVM: Fix UAF in nested posted interrupt processing

2018-12-29T12:37:56+00:00

commit c2dd5146e9fe1f22c77c1b011adf84eea0245806 upstream.

nested_get_vmcs12_pages() processes the posted_intr address in vmcs12. It
caches the kmap()ed page object and pointer, however, it doesn't handle
errors correctly: it's possible to cache a valid pointer, then release
the page and later dereference the dangling pointer.

I was able to reproduce with the following steps:

1. Call vmlaunch with valid posted_intr_desc_addr but an invalid
MSR_EFER. This causes nested_get_vmcs12_pages() to cache the kmap()ed
pi_desc_page and pi_desc. Later the invalid EFER value fails
check_vmentry_postreqs() which fails the first vmlaunch.

2. Call vmlanuch with a valid EFER but an invalid posted_intr_desc_addr
(I set it to 2G - 0x80). The second time we call nested_get_vmcs12_pages
pi_desc_page is unmapped and released and pi_desc_page is set to NULL
(the "shouldn't happen" clause). Due to the invalid
posted_intr_desc_addr, kvm_vcpu_gpa_to_page() fails and
nested_get_vmcs12_pages() returns. It doesn't return an error value so
vmlaunch proceeds. Note that at this time we have a dangling pointer in
vmx->nested.pi_desc and POSTED_INTR_DESC_ADDR in L0's vmcs.

3. Issue an IPI in L2 guest code. This triggers a call to
vmx_complete_nested_posted_interrupt() and pi_test_and_clear_on() which
dereferences the dangling pointer.

Vulnerable code requires nested and enable_apicv variables to be set to
true. The host CPU must also support posted interrupts.

Fixes: 5e2f30b756a37 "KVM: nVMX: get rid of nested_get_page()"
Cc: stable@vger.kernel.org
Reviewed-by: Andy Honig 
Signed-off-by: Cfir Cohen 
Reviewed-by: Liran Alon 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman