PAN fixes backport for v4.4.35
Subsystems (2)
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
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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 2/3 arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call [v4.4]
In reply to James Morsecommit 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
@@ -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
PATCH 3/3 arm64: suspend: Reconfigure PSTATE after resume from idle [v4.4]
In reply to James Morsecommit 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
@@ -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
Greg KH
maintainercover PAN fixes backport for v4.4.35
In reply to James MorseQuoted 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?
thanks,
greg k-h
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.htmlWhy 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
Greg KH
maintainercover 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
cover PAN fixes backport for v4.4.35
In reply to James MorseQuoted 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.htmlPatch 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