Skip to contentSkip to conversation

PAN fixes backport for v4.4.35

PATCH New James Morse 3 participants 8 messages Dec 2, 2016 – Dec 6, 2016

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover PAN fixes backport for v4.4.35

Hi linux-stable,

This is the backport of the recent PAN fixes series for v4.4.35. Original series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html

Patch 1 changes the prototype of all the feature/errata enable calls, so is fiddly to backport, hence doing it later as a separate series.

Patch 3 has had the UAO desription removed from its commit message as v4.4 doesn't support this feature.

Thanks,

James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via

    IPI [v4.4]

arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.4]
arm64: suspend: Reconfigure PSTATE after resume from idle [v4.4]

 arch/arm64/include/asm/cpufeature.h |  2 +-
 arch/arm64/include/asm/processor.h  |  2 +-
 arch/arm64/kernel/cpufeature.c      | 10 +++++++++-
 arch/arm64/kernel/suspend.c         |  9 +++++++++
 arch/arm64/mm/fault.c               | 12 +++++++++++-
 5 files changed, 31 insertions(+), 4 deletions(-)
Signature · 1 line
2.10.1
#1 lore raw

PATCH 1/3 arm64: cpufeature: Schedule enable() calls instead of calling them via IPI [v4.4]

commit 2a6dcb2b5f3e21592ca8dfa198dcce7bec09b020 upstream.

The enable() call for a cpufeature/errata is called using on_each_cpu(). This issues a cross-call IPI to get the work done. Implicitly, this stashes the running PSTATE in SPSR when the CPU receives the IPI, and restores it when we return. This means an enable() call can never modify PSTATE.

To allow PAN to do this, change the on_each_cpu() call to use stop_machine(). This schedules the work on each CPU which allows us to modify PSTATE.

This involves changing the protype of all the enable() functions.

enable_cpu_capabilities() is called during boot and enables the feature on all online CPUs. This path now uses stop_machine(). CPU features for hotplug'd CPUs are enabled by verify_local_cpu_features() which only acts on the local CPU, and can already modify the running PSTATE as it is called from secondary_start_kernel().

[Removed enable() hunks for features/errata v4.4. doesn't have. Changed
caps->enable arg in enable_cpu_capabilities()]

---
 arch/arm64/include/asm/cpufeature.h |  2 +-
 arch/arm64/include/asm/processor.h  |  2 +-
 arch/arm64/kernel/cpufeature.c      | 10 +++++++++-
 arch/arm64/mm/fault.c               |  3 ++-
 4 files changed, 13 insertions(+), 4 deletions(-)
arch/arm64/include/asm/cpufeature.h +1 -1
index 8136afc9df0d..8884b5d5f48c 100644
@@ -77,7 +77,7 @@ struct arm64_cpu_capabilities {
 	const char *desc;
 	u16 capability;
 	bool (*matches)(const struct arm64_cpu_capabilities *);
-	void (*enable)(void *);		/* Called on all active CPUs */
+	int (*enable)(void *);		/* Called on all active CPUs */
 	union {
 		struct {	/* To be used for erratum handling only */
 			u32 midr_model;
arch/arm64/include/asm/processor.h +1 -1
index 4acb7ca94fcd..d08559528927 100644
@@ -186,6 +186,6 @@ static inline void spin_lock_prefetch(const void *x)
 
 #endif
 
-void cpu_enable_pan(void *__unused);
+int cpu_enable_pan(void *__unused);
 
 #endif /* __ASM_PROCESSOR_H */
arch/arm64/kernel/cpufeature.c +9 -1
index 0669c63281ea..2735bf814592 100644
@@ -19,7 +19,9 @@
 #define pr_fmt(fmt) "CPU features: " fmt
 
 #include <linux/bsearch.h>
+#include <linux/cpumask.h>
 #include <linux/sort.h>
+#include <linux/stop_machine.h>
 #include <linux/types.h>
 #include <asm/cpu.h>
 #include <asm/cpufeature.h>
@@ -764,7 +766,13 @@ static void enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
 
 	for (i = 0; caps[i].desc; i++)
 		if (caps[i].enable && cpus_have_cap(caps[i].capability))
-			on_each_cpu(caps[i].enable, NULL, true);
+			/*
+			 * Use stop_machine() as it schedules the work allowing
+			 * us to modify PSTATE, instead of on_each_cpu() which
+			 * uses an IPI, giving us a PSTATE that disappears when
+			 * we return.
+			 */
+			stop_machine(caps[i].enable, NULL, cpu_online_mask);
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
arch/arm64/mm/fault.c +2 -1
index 4c1a118c1d09..d4634e6942ca 100644
@@ -606,8 +606,9 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
 }
 
 #ifdef CONFIG_ARM64_PAN
-void cpu_enable_pan(void *__unused)
+int cpu_enable_pan(void *__unused)
 {
 	config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+	return 0;
 }
 #endif /* CONFIG_ARM64_PAN */
Signature · 1 line
2.10.1
#2 lore raw

PATCH 2/3 arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.4]

In reply to James Morse

commit 7209c868600bd8926e37c10b9aae83124ccc1dd8 upstream.

Commit 338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1. This means the PSTATE.PAN bit won't be set until the next return to the kernel from userspace. On a preemptible kernel we may schedule work that accesses userspace on a CPU before it has done this.

Now that cpufeature enable() calls are scheduled via stop_machine(), we can set PSTATE.PAN from the cpu_enable_pan() call.

Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated is not immediately discarded.

---
 arch/arm64/mm/fault.c | 9 +++++++++
 1 file changed, 9 insertions(+)
arch/arm64/mm/fault.c +9 -0
index d4634e6942ca..247bae758e1e 100644
@@ -29,7 +29,9 @@
 #include <linux/sched.h>
 #include <linux/highmem.h>
 #include <linux/perf_event.h>
+#include <linux/preempt.h>
 
+#include <asm/bug.h>
 #include <asm/cpufeature.h>
 #include <asm/exception.h>
 #include <asm/debug-monitors.h>
@@ -608,7 +610,14 @@ asmlinkage int __exception do_debug_exception(unsigned long addr,
 #ifdef CONFIG_ARM64_PAN
 int cpu_enable_pan(void *__unused)
 {
+	/*
+	 * We modify PSTATE. This won't work from irq context as the PSTATE
+	 * is discarded once we return from the exception.
+	 */
+	WARN_ON_ONCE(in_interrupt());
+
 	config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+	asm(SET_PSTATE_PAN(1));
 	return 0;
 }
 #endif /* CONFIG_ARM64_PAN */
Signature · 1 line
2.10.1
#3 lore raw

PATCH 3/3 arm64: suspend: Reconfigure PSTATE after resume from idle [v4.4]

In reply to James Morse

commit d08544127d9fb4505635e3cb6871fd50a42947bd upstream.

The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not save/restore PSTATE. As a result of this cpufeatures that were detected and have bits in PSTATE get lost when we resume from idle.

PAN will be re-enabled next time we return from user-space, but on a preemptible kernel we may run work accessing user space before this point.

Add code to re-enable this feature in __cpu_suspend_exit().

[Removed UAO hooks and commit-message references: this feature is not
present in v4.4]

---
 arch/arm64/kernel/suspend.c | 9 +++++++++
 1 file changed, 9 insertions(+)
arch/arm64/kernel/suspend.c +9 -0
index 1095aa483a1c..00c1372bf57b 100644
@@ -1,7 +1,9 @@
 #include <linux/ftrace.h>
 #include <linux/percpu.h>
 #include <linux/slab.h>
+#include <asm/alternative.h>
 #include <asm/cacheflush.h>
+#include <asm/cpufeature.h>
 #include <asm/debug-monitors.h>
 #include <asm/pgtable.h>
 #include <asm/memory.h>
@@ -111,6 +113,13 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 		set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
 
 		/*
+		 * PSTATE was not saved over suspend/resume, re-enable any
+		 * detected features that might not have been set correctly.
+		 */
+		asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,
+				CONFIG_ARM64_PAN));
+
+		/*
 		 * Restore HW breakpoint registers to sane values
 		 * before debug exceptions are possibly reenabled
 		 * through local_dbg_restore.
Signature · 1 line
2.10.1
#5 lore raw

cover PAN fixes backport for v4.4.35

Hi Greg,

Quoted 8 lines · Greg KH
Quoted 5 lines · James Morse

Hi linux-stable,

This is the backport of the recent PAN fixes series for v4.4.35. Original series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html

Why just 4.4-stable? What about 4.8-stable?

Patch 1 doesn't backport easily. I was going to do v4.8 next, but thought one at a time would be the least confusing...

(I don't seem to be very good at predicting what is confusing!)

Thanks,

James

maintainer
#6 lore raw

cover PAN fixes backport for v4.4.35

Quoted 10 lines · James Morse

Hi Greg,

Quoted 7 lines · Greg KH
Quoted 5 lines · James Morse

Hi linux-stable,

This is the backport of the recent PAN fixes series for v4.4.35. Original series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html

Quoted 6 lines
Quoted 1 line

Why just 4.4-stable? What about 4.8-stable?

Patch 1 doesn't backport easily. I was going to do v4.8 next, but thought one at a time would be the least confusing...

(I don't seem to be very good at predicting what is confusing!)

Adding a patch to an "old" stable kernel would be odd if the latest stable kernel also doesn't have it, right? I need for it to be in 4.8 before I can take it into 4.4, sorry.

So I'll hold off on applying these until that happens.

thanks,

greg k-h

#7 lore raw

cover PAN fixes backport for v4.4.35

In reply to James Morse
Quoted 11 lines · James Morse

Hi linux-stable,

This is the backport of the recent PAN fixes series for v4.4.35. Original series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html

Patch 1 changes the prototype of all the feature/errata enable calls, so is fiddly to backport, hence doing it later as a separate series.

Patch 3 has had the UAO desription removed from its commit message as v4.4 doesn't support this feature.

Thanks, now all queued up.

greg k-h