Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Thanks,
Will
--->8
The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:
Linux 4.15 (2018-01-28 13:20:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-spectre-meltdown-for-4.15-stable
for you to fetch changes up to a4c4410bae3dc1f00ab3bfb9d425740bf197b5b6:
[Variant 2/Spectre-v2] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround (2018-02-07 15:48:57 +0000)
---------------------------------------------------------------- arm64 Spectre and Meltdown mitigations based on v4.15
---------------------------------------------------------------- Catalin Marinas (1): [Variant 3/Meltdown] arm64: kpti: Fix the interaction between ASID switching and software PAN
Dan Williams (1): [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
James Morse (1): [Variant 2/Spectre-v2] arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early
Jayachandran C (3): [Variant 3/Meltdown] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs [Variant 3/Meltdown] arm64: Turn on KPTI only on CPUs that need it [Variant 2/Spectre-v2] arm64: Branch predictor hardening for Cavium ThunderX2
Marc Zyngier (20): [Variant 3/Meltdown] arm64: Force KPTI to be disabled on Cavium ThunderX [Variant 2/Spectre-v2] arm64: Move post_ttbr_update_workaround to C code [Variant 2/Spectre-v2] arm64: Move BP hardening to check_and_switch_context [Variant 2/Spectre-v2] arm64: KVM: Use per-CPU vector when BP hardening is enabled [Variant 2/Spectre-v2] arm64: KVM: Increment PC after handling an SMC trap [Variant 2/Spectre-v2] arm/arm64: KVM: Consolidate the PSCI include files [Variant 2/Spectre-v2] arm/arm64: KVM: Add PSCI_VERSION helper [Variant 2/Spectre-v2] arm/arm64: KVM: Add smccc accessors to PSCI code [Variant 2/Spectre-v2] arm/arm64: KVM: Implement PSCI 1.0 support [Variant 2/Spectre-v2] arm/arm64: KVM: Advertise SMCCC v1.1 [Variant 2/Spectre-v2] arm64: KVM: Make PSCI_VERSION a fast path [Variant 2/Spectre-v2] arm/arm64: KVM: Turn kvm_psci_version into a static inline [Variant 2/Spectre-v2] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening support [Variant 2/Spectre-v2] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling [Variant 2/Spectre-v2] firmware/psci: Expose PSCI conduit [Variant 2/Spectre-v2] firmware/psci: Expose SMCCC version through psci_ops [Variant 2/Spectre-v2] arm/arm64: smccc: Make function identifiers an unsigned quantity [Variant 2/Spectre-v2] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive [Variant 2/Spectre-v2] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support [Variant 2/Spectre-v2] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
Mark Rutland (1): [Variant 1/Spectre-v1] Documentation: Document array_index_nospec
Robin Murphy (3): [Variant 1/Spectre-v1] arm64: Implement array_index_mask_nospec() [Variant 1/Spectre-v1] arm64: Make USER_DS an inclusive limit [Variant 1/Spectre-v1] arm64: Use pointer masking to limit uaccess speculation
Shanker Donthineni (1): [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor
Stephen Boyd (1): [Variant 3/Meltdown] arm64: cpu_errata: Add Kryo to Falkor 1003 errata
Suzuki K Poulose (2): [Variant 3/Meltdown] arm64: capabilities: Handle duplicate entries for a capability [Variant 2/Spectre-v2] arm64: Run enable method for errata work arounds on late CPUs
Will Deacon (41): [Variant 3/Meltdown] arm64: mm: Use non-global mappings for kernel space [Variant 3/Meltdown] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN [Variant 3/Meltdown] arm64: mm: Move ASID from TTBR0 to TTBR1 [Variant 3/Meltdown] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 [Variant 3/Meltdown] arm64: mm: Rename post_ttbr0_update_workaround [Variant 3/Meltdown] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN [Variant 3/Meltdown] arm64: mm: Allocate ASIDs in pairs [Variant 3/Meltdown] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper [Variant 3/Meltdown] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI [Variant 3/Meltdown] arm64: entry: Add exception trampoline page for exceptions from EL0 [Variant 3/Meltdown] arm64: mm: Map entry trampoline into trampoline and kernel page tables [Variant 3/Meltdown] arm64: entry: Explicitly pass exception level to kernel_ventry macro [Variant 3/Meltdown] arm64: entry: Hook up entry trampoline to exception vectors [Variant 3/Meltdown] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code [Variant 3/Meltdown] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks [Variant 3/Meltdown] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 [Variant 3/Meltdown] arm64: kaslr: Put kernel vectors address in separate data page [Variant 3/Meltdown] arm64: use RET instruction for exiting the trampoline [Variant 3/Meltdown] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 [Variant 3/Meltdown] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry [Variant 3/Meltdown] arm64: Take into account ID_AA64PFR0_EL1.CSV3 [Variant 3/Meltdown] arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR [Variant 3/Meltdown] arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() [Variant 3/Meltdown] arm64: mm: Permit transitioning from Global to Non-Global without BBM [Variant 3/Meltdown] arm64: kpti: Add ->enable callback to remap swapper using nG mappings [Variant 3/Meltdown] arm64: entry: Reword comment about post_ttbr_update_workaround [Variant 3/Meltdown] arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives [Variant 3/Meltdown] perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0() [Variant 1/Spectre-v1] arm64: barrier: Add CSDB macros to control data-value prediction [Variant 1/Spectre-v1] arm64: entry: Ensure branch through syscall table is bounded under speculation [Variant 1/Spectre-v1] arm64: uaccess: Prevent speculative use of the current addr_limit [Variant 1/Spectre-v1] arm64: uaccess: Don't bother eliding access_ok checks in __{get, put}_user [Variant 1/Spectre-v1] arm64: uaccess: Mask __user pointers for __arch_{clear, copy_*}_user [Variant 1/Spectre-v1] arm64: futex: Mask __user pointers prior to dereference [Variant 2/Spectre-v2] arm64: cpufeature: Pass capability structure to ->enable callback [Variant 2/Spectre-v2] drivers/firmware: Expose psci_get_version through psci_ops structure [Variant 2/Spectre-v2] arm64: Add skeleton to harden the branch predictor against aliasing attacks [Variant 2/Spectre-v2] arm64: entry: Apply BP hardening for high-priority synchronous exceptions [Variant 2/Spectre-v2] arm64: entry: Apply BP hardening for suspicious interrupts from EL0 [Variant 2/Spectre-v2] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
Documentation/arm64/silicon-errata.txt | 2 +- Documentation/speculation.txt | 90 +++++++++++++ arch/arm/include/asm/kvm_host.h | 6 + arch/arm/include/asm/kvm_mmu.h | 10 ++ arch/arm/include/asm/kvm_psci.h | 27 ---- arch/arm/kvm/handle_exit.c | 4 +- arch/arm64/Kconfig | 46 +++++-- arch/arm64/include/asm/asm-uaccess.h | 36 +++-- arch/arm64/include/asm/assembler.h | 54 +++----- arch/arm64/include/asm/barrier.h | 22 +++ arch/arm64/include/asm/cpucaps.h | 5 +- arch/arm64/include/asm/cputype.h | 9 ++ arch/arm64/include/asm/efi.h | 12 +- arch/arm64/include/asm/fixmap.h | 5 + arch/arm64/include/asm/futex.h | 9 +- arch/arm64/include/asm/kvm_asm.h | 2 + arch/arm64/include/asm/kvm_host.h | 5 + arch/arm64/include/asm/kvm_mmu.h | 38 ++++++ arch/arm64/include/asm/kvm_psci.h | 27 ---- arch/arm64/include/asm/mmu.h | 48 +++++++ arch/arm64/include/asm/mmu_context.h | 12 +- arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/include/asm/pgtable-prot.h | 35 +++-- arch/arm64/include/asm/pgtable.h | 1 + arch/arm64/include/asm/proc-fns.h | 6 - arch/arm64/include/asm/processor.h | 3 + arch/arm64/include/asm/sysreg.h | 2 + arch/arm64/include/asm/tlbflush.h | 16 ++- arch/arm64/include/asm/uaccess.h | 181 +++++++++++++++++-------- arch/arm64/kernel/Makefile | 4 + arch/arm64/kernel/arm64ksyms.c | 4 +- arch/arm64/kernel/asm-offsets.c | 6 +- arch/arm64/kernel/bpi.S | 83 ++++++++++++ arch/arm64/kernel/cpu-reset.S | 2 +- arch/arm64/kernel/cpu_errata.c | 239 ++++++++++++++++++++++++++++++++- arch/arm64/kernel/cpufeature.c | 138 +++++++++++++++---- arch/arm64/kernel/entry.S | 228 ++++++++++++++++++++++++++----- arch/arm64/kernel/head.S | 2 +- arch/arm64/kernel/process.c | 12 +- arch/arm64/kernel/sleep.S | 2 +- arch/arm64/kernel/vmlinux.lds.S | 22 ++- arch/arm64/kvm/handle_exit.c | 14 +- arch/arm64/kvm/hyp/entry.S | 12 ++ arch/arm64/kvm/hyp/hyp-entry.S | 20 ++- arch/arm64/kvm/hyp/switch.c | 13 +- arch/arm64/lib/clear_user.S | 10 +- arch/arm64/lib/copy_from_user.S | 4 +- arch/arm64/lib/copy_in_user.S | 9 +- arch/arm64/lib/copy_to_user.S | 4 +- arch/arm64/mm/cache.S | 4 +- arch/arm64/mm/context.c | 48 ++++--- arch/arm64/mm/fault.c | 36 ++++- arch/arm64/mm/mmu.c | 35 +++++ arch/arm64/mm/proc.S | 224 +++++++++++++++++++++++++++--- arch/arm64/xen/hypercall.S | 4 +- drivers/firmware/psci.c | 57 +++++++- drivers/perf/arm_spe_pmu.c | 9 ++ include/kvm/arm_psci.h | 51 +++++++ include/linux/arm-smccc.h | 165 ++++++++++++++++++++++- include/linux/nospec.h | 72 ++++++++++ include/linux/psci.h | 14 ++ include/uapi/linux/psci.h | 3 + virt/kvm/arm/arm.c | 10 +- virt/kvm/arm/psci.c | 143 ++++++++++++++++---- 64 files changed, 2049 insertions(+), 368 deletions(-) create mode 100644 Documentation/speculation.txt delete mode 100644 arch/arm/include/asm/kvm_psci.h delete mode 100644 arch/arm64/include/asm/kvm_psci.h create mode 100644 arch/arm64/kernel/bpi.S create mode 100644 include/kvm/arm_psci.h create mode 100644 include/linux/nospec.h
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
greg k-h
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Will
On Fri, Feb 09, 2018 at 01:51:31PM +0000, Will Deacon wrote:
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Ok, then it's not a big deal to wait a few more days :)
Maybe by then we can have the 4.14 patches at the same time...
thanks,
greg k-h
On Fri, Feb 09, 2018 at 04:04:36PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:51:31PM +0000, Will Deacon wrote:
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Ok, then it's not a big deal to wait a few more days :)
All now queued up, thanks!
greg k-h
Hey Greg,
On Tue, Feb 13, 2018 at 05:48:59PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 04:04:36PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:51:31PM +0000, Will Deacon wrote:
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Ok, then it's not a big deal to wait a few more days :)
All now queued up, thanks!
Good to hear, thanks! Could you also queue the 4.14 backport [1], please? Having this in an LTS would be really handy.
Cheers,
Will
[1] http://lkml.kernel.org/r/20180212113801.2552-1-ard.biesheuvel@linaro.org
On Wed, Feb 14, 2018 at 12:41:01PM +0000, Will Deacon wrote:
Hey Greg,
On Tue, Feb 13, 2018 at 05:48:59PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 04:04:36PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:51:31PM +0000, Will Deacon wrote:
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Note that there are two commits in here that are already in stable:
9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references
so you can skip those when applying.
Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Ok, then it's not a big deal to wait a few more days :)
All now queued up, thanks!
Good to hear, thanks! Could you also queue the 4.14 backport [1], please? Having this in an LTS would be really handy.
Yes, please give me a chance, I have 240+ pending stable patches at the moment to dig through :)
thanks,
greg kh
On Wed, Feb 14, 2018 at 01:54:03PM +0100, Greg KH wrote:
On Wed, Feb 14, 2018 at 12:41:01PM +0000, Will Deacon wrote:
Hey Greg,
On Tue, Feb 13, 2018 at 05:48:59PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 04:04:36PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:51:31PM +0000, Will Deacon wrote:
On Fri, Feb 09, 2018 at 02:49:57PM +0100, Greg KH wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote: > Hi Greg, > > I've put together a tag which includes all of the upstream arm64 spectre and > meltdown mitigations based on v4.15. Please could you consider taking this > into the 4.15 stable tree? > > I understand that Ard (cc'd) is using this stack to create a version for 4.14 > too. > > Note that there are two commits in here that are already in stable: > > 9c9345fb26ff [Variant 1/Spectre-v1] Documentation: Document array_index_nospec > 60d6c8a8e54e [Variant 1/Spectre-v1] array_index_nospec: Sanitize speculative array de-references > > so you can skip those when applying. > > Please shout if you run into trouble.
Ah, nice, thanks for this. I'll use this for the next 4.15.y kernel release after the one I _just_ sent out for review a few minutes ago.
Cool, sorry for the unfortunate timing. This only hit mainline last night.
Ok, then it's not a big deal to wait a few more days :)
All now queued up, thanks!
Good to hear, thanks! Could you also queue the 4.14 backport [1], please? Having this in an LTS would be really handy.
Yes, please give me a chance, I have 240+ pending stable patches at the moment to dig through :)
Ok, now queued up, but there were some conflicts, so checking I got it all correct would be wonderful.
thanks,
greg k-h
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Do you know of anyone working on backporting this patch series to older stable trees (i.e. 4.9.y and 4.4.y and possibly 3.18.y?)
I had some requests by some chip manufacturers who were wondering about this, as they seem to be stuck on older kernels (of their own doing, not our fault at all...)
If not, no big deal, I'll just tell them they need to do the work themselves if they care about those old kernel trees :)
thanks,
greg k-h
On 21 February 2018 at 12:53, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Do you know of anyone working on backporting this patch series to older stable trees (i.e. 4.9.y and 4.4.y and possibly 3.18.y?)
I had some requests by some chip manufacturers who were wondering about this, as they seem to be stuck on older kernels (of their own doing, not our fault at all...)
If not, no big deal, I'll just tell them they need to do the work themselves if they care about those old kernel trees :)
I had a stab at applying this series to v4.9 LTS as well as our own v4.9 LTS based stable tree (which has backports of lots of arch/arm64 features applied on top), but there are just too many conflicts. Functionally, I don't think there are any real impediments, but the interaction with things like PAN emulation and the feature/errata/alternatives framework make backporting rather tedious. Combined with the fact that the Meltdown threat is rather theoretical for most things already deployed, I am not convinced that we are likely to end up with something that is more secure than what we started with.
In any case, I don't think this series should serve as the basis for a backport to v4.9 and earlier, and instead, it should probably focus on Spectre mitigation only (which is less intrusive AFAICT). We have someone in Linaro who is in charge of our stable kernel trees, but he will need help from someone who intimately understands the code. My focus was v4.14 primarily because of the significance to my team (the enterprise group in Linaro), and I cannot justify spending a disproportionate amount of time on kernel versions our members don't care about.
On Wed, Feb 21, 2018 at 01:43:34PM +0000, Ard Biesheuvel wrote:
On 21 February 2018 at 12:53, Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Feb 09, 2018 at 01:48:11PM +0000, Will Deacon wrote:
Hi Greg,
I've put together a tag which includes all of the upstream arm64 spectre and meltdown mitigations based on v4.15. Please could you consider taking this into the 4.15 stable tree?
I understand that Ard (cc'd) is using this stack to create a version for 4.14 too.
Do you know of anyone working on backporting this patch series to older stable trees (i.e. 4.9.y and 4.4.y and possibly 3.18.y?)
I had some requests by some chip manufacturers who were wondering about this, as they seem to be stuck on older kernels (of their own doing, not our fault at all...)
If not, no big deal, I'll just tell them they need to do the work themselves if they care about those old kernel trees :)
I had a stab at applying this series to v4.9 LTS as well as our own v4.9 LTS based stable tree (which has backports of lots of arch/arm64 features applied on top), but there are just too many conflicts. Functionally, I don't think there are any real impediments, but the interaction with things like PAN emulation and the feature/errata/alternatives framework make backporting rather tedious. Combined with the fact that the Meltdown threat is rather theoretical for most things already deployed, I am not convinced that we are likely to end up with something that is more secure than what we started with.
Ugh, I was worried about PAN stuff :(
I'm guessing that the android-common trees might have an easier time of this, I'll go ask the Google developers what they are considering for these trees.
In any case, I don't think this series should serve as the basis for a backport to v4.9 and earlier, and instead, it should probably focus on Spectre mitigation only (which is less intrusive AFAICT).
But we have x86 already working for 4.9.y :)
We have someone in Linaro who is in charge of our stable kernel trees, but he will need help from someone who intimately understands the code. My focus was v4.14 primarily because of the significance to my team (the enterprise group in Linaro), and I cannot justify spending a disproportionate amount of time on kernel versions our members don't care about.
Fair enough, it makes sense not to drag this back to older kernels unless someone really cares about it. Thanks for the quick response, I'll push back on the people asking about it to see if they even can detect the issue on their devices...
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Ard Biesheuvel -
Greg KH -
Will Deacon