linux-stable.git/arch/arm64, branch v4.7.2

arm64: hibernate: handle allocation failures

2016-08-20T16:10:50+00:00

commit dfbca61af0b654990b9af8297ac574a9986d8275 upstream.

In create_safe_exec_page(), we create a copy of the hibernate exit text,
along with some page tables to map this via TTBR0. We then install the
new tables in TTBR0.

In swsusp_arch_resume() we call create_safe_exec_page() before trying a
number of operations which may fail (e.g. copying the linear map page
tables). If these fail, we bail out of swsusp_arch_resume() and return
an error code, but leave TTBR0 as-is. Subsequently, the core hibernate
code will call free_basic_memory_bitmaps(), which will free all of the
memory allocations we made, including the page tables installed in
TTBR0.

Thus, we may have TTBR0 pointing at dangling freed memory for some
period of time. If the hibernate attempt was triggered by a user
requesting a hibernate test via the reboot syscall, we may return to
userspace with the clobbered TTBR0 value.

Avoid these issues by reorganising swsusp_arch_resume() such that we
have no failure paths after create_safe_exec_page(). We also add a check
that the zero page allocation succeeded, matching what we have for other
allocations.

Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk")
Signed-off-by: Mark Rutland 
Acked-by: James Morse 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: hibernate: avoid potential TLB conflict

2016-08-20T16:10:50+00:00

commit 0194e760f7d2f42adb5e1db31b27a4331dd89c2f upstream.

In create_safe_exec_page we install a set of global mappings in TTBR0,
then subsequently invalidate TLBs. While TTBR0 points at the zero page,
and the TLBs should be free of stale global entries, we may have stale
ASID-tagged entries (e.g. from the EFI runtime services mappings) for
the same VAs. Per the ARM ARM these ASID-tagged entries may conflict
with newly-allocated global entries, and we must follow a
Break-Before-Make approach to avoid issues resulting from this.

This patch reworks create_safe_exec_page to invalidate TLBs while the
zero page is still in place, ensuring that there are no potential
conflicts when the new TTBR0 value is installed. As a single CPU is
online while this code executes, we do not need to perform broadcast TLB
maintenance, and can call local_flush_tlb_all(), which also subsumes
some barriers. The remaining assembly is converted to use write_sysreg()
and isb().

Other than this, we safely manipulate TTBRs in the hibernate dance. The
code we install as part of the new TTBR0 mapping (the hibernated
kernel's swsusp_arch_suspend_exit) installs a zero page into TTBR1,
invalidates TLBs, then installs its preferred value. Upon being restored
to the middle of swsusp_arch_suspend, the new image will call
__cpu_suspend_exit, which will call cpu_uninstall_idmap, installing the
zero page in TTBR0 and invalidating all TLB entries.

Fixes: 82869ac57b5d ("arm64: kernel: Add support for hibernate/suspend-to-disk")
Signed-off-by: Mark Rutland 
Acked-by: James Morse 
Tested-by: James Morse 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Set cpsr before spsr on fault injection

2016-08-20T16:10:50+00:00

commit 89581f06b2bc225f0c9822fa52e714aa2e3810dd upstream.

We need to set cpsr before determining the spsr bank, as the bank
depends on the target exception level of the injection, not the
current mode of the vcpu. Normally this is one in the same (EL1),
but not when we manage to trap an EL0 fault. It still doesn't really
matter for the 64-bit EL0 case though, as vcpu_spsr() unconditionally
uses the EL1 bank for that. However the 32-bit EL0 case gets fun, as
that path will lead to the BUG() in vcpu_spsr32().

This patch fixes the assignment order and also modifies some white
space in order to better group pairs of lines that have strict order.

Signed-off-by: Andrew Jones 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

arm64: vmlinux.lds: make __rela_offset and __dynsym_offset ABSOLUTE

2016-08-20T16:10:50+00:00

commit d6732fc402c2665f61e72faf206a0268e65236e9 upstream.

Due to the untyped KIMAGE_VADDR constant, the linker may not notice
that the __rela_offset and __dynsym_offset expressions are absolute
values (i.e., are not subject to relocation). This does not matter for
KASLR, but it does confuse kallsyms in relative mode, since it uses
the lowest non-absolute symbol address as the anchor point, and expects
all other symbol addresses to be within 4 GB of it.

Fix this by qualifying these expressions as ABSOLUTE() explicitly.

Fixes: 0cd3defe0af4 ("arm64: kernel: perform relocation processing from ID map")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: mm: avoid fdt_check_header() before the FDT is fully mapped

2016-08-20T16:10:50+00:00

commit 04a848106193b134741672f7e4e444b50c70b631 upstream.

As reported by Zijun, the fdt_check_header() call in __fixmap_remap_fdt()
is not safe since it is not guaranteed that the FDT header is mapped
completely. Due to the minimum alignment of 8 bytes, the only fields we
can assume to be mapped are 'magic' and 'totalsize'.

Since the OF layer is in charge of validating the FDT image, and we are
only interested in making reasonably sure that the size field contains
a meaningful value, replace the fdt_check_header() call with an explicit
comparison of the magic field's value against the expected value.

Reported-by: Zijun Hu 
Acked-by: Mark Rutland 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: dts: rockchip: fixes the gic400 2nd region size for rk3368

2016-08-20T16:10:50+00:00

commit ad1cfdf518976447e6b0d31517bad4e3ebbce6bb upstream.

The 2nd additional region is the GIC virtual cpu interface register
base and size.

As the gic400 of rk3368 says, the cpu interface register map as below

:

-0x0000 GICC_CTRL
.
.
.
-0x00fc GICC_IIDR
-0x1000 GICC_IDR

Obviously, the region size should be greater than 0x1000.
So we should make sure to include the GICC_IDR since the kernel will access
it in some cases.

Fixes: b790c2cab5ca ("arm64: dts: add Rockchip rk3368 core dtsi and board dts for the r88 board")
Signed-off-by: Caesar Wang 
Reviewed-by: Shawn Lin 
Signed-off-by: Greg Kroah-Hartman 

[added Fixes and stable-cc]
Signed-off-by: Heiko Stuebner

arm64: Honor nosmp kernel command line option

2016-08-20T16:10:49+00:00

commit e75118a7b581b19b08282c7819c1ec6f68b91b79 upstream.

Passing "nosmp" should boot the kernel with a single processor, without
provision to enable secondary CPUs even if they are present. "nosmp" is
implemented by setting maxcpus=0. At the moment we still mark the secondary
CPUs present even with nosmp, which allows the userspace to bring them
up. This patch corrects the smp_prepare_cpus() to honor the maxcpus == 0.

Commit 44dbcc93ab67145 ("arm64: Fix behavior of maxcpus=N") fixed the
behavior for maxcpus >= 1, but broke maxcpus = 0.

Fixes: 44dbcc93ab67 ("arm64: Fix behavior of maxcpus=N")
Cc: Will Deacon 
Cc: James Morse 
Signed-off-by: Suzuki K Poulose 
Acked-by: Mark Rutland 
[catalin.marinas@arm.com: updated code comment]
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: Only select ARM64_MODULE_PLTS if MODULES=y

2016-08-20T16:10:49+00:00

commit b9c220b589daaf140f5b8ebe502c98745b94e65c upstream.

Selecting CONFIG_RANDOMIZE_BASE=y and CONFIG_MODULES=n fails to build
the module PLTs support:

  CC      arch/arm64/kernel/module-plts.o
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/module-plts.c: In function ‘module_emit_plt_entry’:
/work/Linux/linux-2.6-aarch64/arch/arm64/kernel/module-plts.c:32:49: error: dereferencing pointer to incomplete type ‘struct module’

This patch selects ARM64_MODULE_PLTS conditionally only if MODULES is
enabled.

Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
Reported-by: Jeff Vander Stoep 
Acked-by: Ard Biesheuvel 
Acked-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: Fix incorrect per-cpu usage for boot CPU

2016-08-20T16:10:49+00:00

commit 9113c2aa05e9848cd4f1154abee17d4f265f012d upstream.

In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to  store
the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for
the boot CPU. This patch reorders the sequence to make sure we initialise
the per-cpu offset before accessing the per-cpu area.

Commit 4b998ff1885eec ("arm64: Delay cpuinfo_store_boot_cpu") fixed the
issue where we modified the per-cpu area even before the kernel initialises
the per-cpu areas, but failed to wait until the boot cpu updated it's
offset.

Fixes: 4b998ff1885e ("arm64: Delay cpuinfo_store_boot_cpu")
Cc: Will Deacon 
Signed-off-by: Suzuki K Poulose 
Acked-by: Mark Rutland 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman

arm64: debug: unmask PSTATE.D earlier

2016-08-20T16:10:49+00:00

commit 2ce39ad15182604beb6c8fa8bed5e46b59fd1082 upstream.

Clearing PSTATE.D is one of the requirements for generating a debug
exception. The arm64 booting protocol requires that PSTATE.D is set,
since many of the debug registers (for example, the hw_breakpoint
registers) are UNKNOWN out of reset and could potentially generate
spurious, fatal debug exceptions in early boot code if PSTATE.D was
clear. Once the debug registers have been safely initialised, PSTATE.D
is cleared, however this is currently broken for two reasons:

(1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary
    CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall
    runs after SMP (and the scheduler) have been initialised, there is
    no guarantee that it is actually running on the boot CPU. In this
    case, the boot CPU is left with PSTATE.D set and is not capable of
    generating debug exceptions.

(2) In a preemptible kernel, we may explicitly schedule on the IRQ
    return path to EL1. If an IRQ occurs with PSTATE.D set in the idle
    thread, then we may schedule the kthread_init thread, run the
    postcore_initcall to clear PSTATE.D and then context switch back
    to the idle thread before returning from the IRQ. The exception
    return path will then restore PSTATE.D from the stack, and set it
    again.

This patch fixes the problem by moving the clearing of PSTATE.D earlier
to proc.S. This has the desirable effect of clearing it in one place for
all CPUs, long before we have to worry about the scheduler or any
exception handling. We ensure that the previous reset of MDSCR_EL1 has
completed before unmasking the exception, so that any spurious
exceptions resulting from UNKNOWN debug registers are not generated.

Without this patch applied, the kprobes selftests have been seen to fail
under KVM, where we end up attempting to step the OOL instruction buffer
with PSTATE.D set and therefore fail to complete the step.

Acked-by: Mark Rutland 
Reported-by: Catalin Marinas 
Tested-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Reviewed-by: Catalin Marinas 
Tested-by: Catalin Marinas 
Signed-off-by: Catalin Marinas 
Signed-off-by: Greg Kroah-Hartman