]> git.baikalelectronics.ru Git - kernel.git/commit
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
authorNicholas Piggin <npiggin@gmail.com>
Wed, 6 Dec 2017 08:21:14 +0000 (18:21 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Wed, 6 Dec 2017 12:32:43 +0000 (23:32 +1100)
commit2e14c8f58755da8bdfa905c4a1dc3de9accb21cf
tree8d79b05a1eefebc306f47294a33b6a5a3597e10e
parent5d039ddae7114fe51699df1bb8addf9dc9f32ddb
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table

kexec can leave MMU registers set when booting into a new kernel,
the PIDR (Process Identification Register) in particular. The boot
sequence does not zero PIDR, so it only gets set when CPUs first
switch to a userspace processes (until then it's running a kernel
thread with effective PID = 0).

This leaves a window where a process table entry and page tables are
set up due to user processes running on other CPUs, that happen to
match with a stale PID. The CPU with that PID may cause speculative
accesses that address quadrant 0 (aka userspace addresses), which will
result in cached translations and PWC (Page Walk Cache) for that
process, on a CPU which is not in the mm_cpumask and so they will not
be invalidated properly.

The most common result is the kernel hanging in infinite page fault
loops soon after kexec (usually in schedule_tail, which is usually the
first non-speculative quadrant 0 access to a new PID) due to a stale
PWC. However being a stale translation error, it could result in
anything up to security and data corruption problems.

Fix this by zeroing out PIDR at boot and kexec.

Fixes: e32967016d38 ("powerpc/mm/radix: Add mmu context handling callback for radix")
Cc: stable@vger.kernel.org # v4.7+
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
arch/powerpc/kernel/cpu_setup_power.S