| Message ID | 1512563739-25239-1-git-send-email-will.deacon@arm.com |
|---|---|
| Headers | show |
| Series | arm64: Unmap the kernel whilst running in userspace (KPTI) | expand |
On 12/06/2017 04:35 AM, Will Deacon wrote: > Hi everybody, > > This is version three of the patches formerly known as KAISER (♔). > > v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html > v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/544817.html > > Changes since v2 include: > > * Rename command-line option from "kaiser=" to "kpti=" for parity with x86 > * Fixed Falkor erratum workaround (missing '~') > * Moved vectors base from literal pool into separate data page > * Added TTBR_ASID_MASK instead of open-coded constants > * Added missing newline to error message > * Fail to probe SPE if KPTI is enabled > * Addressed minor review comments > * Added tags > * Based on -rc2 > > Patches are also pushed here: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > > Feedback and testing welcome. At this point, I'd like to start thinking > about getting this merged for 4.16. > You can add Tested-by: Laura Abbott <labbott@redhat.com> > Cheers, > > Will > > --->8 > > Will Deacon (20): > arm64: mm: Use non-global mappings for kernel space > arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN > arm64: mm: Move ASID from TTBR0 to TTBR1 > arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum > #E1003 > arm64: mm: Rename post_ttbr0_update_workaround > arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN > arm64: mm: Allocate ASIDs in pairs > arm64: mm: Add arm64_kernel_unmapped_at_el0 helper > arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI > arm64: entry: Add exception trampoline page for exceptions from EL0 > arm64: mm: Map entry trampoline into trampoline and kernel page tables > arm64: entry: Explicitly pass exception level to kernel_ventry macro > arm64: entry: Hook up entry trampoline to exception vectors > arm64: erratum: Work around Falkor erratum #E1003 in trampoline code > arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native > tasks > arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 > arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 > perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0() > arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the > TTBR > arm64: kaslr: Put kernel vectors address in separate data page > > arch/arm64/Kconfig | 30 +++-- > arch/arm64/include/asm/asm-uaccess.h | 26 ++-- > arch/arm64/include/asm/assembler.h | 27 +---- > arch/arm64/include/asm/cpucaps.h | 3 +- > arch/arm64/include/asm/fixmap.h | 5 + > arch/arm64/include/asm/kernel-pgtable.h | 12 +- > arch/arm64/include/asm/mmu.h | 11 ++ > arch/arm64/include/asm/mmu_context.h | 9 +- > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > arch/arm64/include/asm/pgtable-prot.h | 21 +++- > arch/arm64/include/asm/pgtable.h | 1 + > arch/arm64/include/asm/proc-fns.h | 6 - > arch/arm64/include/asm/tlbflush.h | 16 ++- > arch/arm64/include/asm/uaccess.h | 21 +++- > arch/arm64/kernel/asm-offsets.c | 6 +- > arch/arm64/kernel/cpufeature.c | 41 +++++++ > arch/arm64/kernel/entry.S | 203 +++++++++++++++++++++++++++----- > arch/arm64/kernel/process.c | 12 +- > arch/arm64/kernel/vmlinux.lds.S | 40 ++++++- > arch/arm64/lib/clear_user.S | 2 +- > arch/arm64/lib/copy_from_user.S | 2 +- > arch/arm64/lib/copy_in_user.S | 2 +- > arch/arm64/lib/copy_to_user.S | 2 +- > arch/arm64/mm/cache.S | 2 +- > arch/arm64/mm/context.c | 36 +++--- > arch/arm64/mm/mmu.c | 31 +++++ > arch/arm64/mm/proc.S | 12 +- > arch/arm64/xen/hypercall.S | 2 +- > drivers/perf/arm_spe_pmu.c | 9 ++ > 29 files changed, 454 insertions(+), 137 deletions(-) >
On Thu, Dec 07, 2017 at 04:40:05PM -0800, Laura Abbott wrote: > On 12/06/2017 04:35 AM, Will Deacon wrote: > >Hi everybody, > > > >This is version three of the patches formerly known as KAISER (♔). > > > > v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html > > v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/544817.html > > > >Changes since v2 include: > > > > * Rename command-line option from "kaiser=" to "kpti=" for parity with x86 > > * Fixed Falkor erratum workaround (missing '~') > > * Moved vectors base from literal pool into separate data page > > * Added TTBR_ASID_MASK instead of open-coded constants > > * Added missing newline to error message > > * Fail to probe SPE if KPTI is enabled > > * Addressed minor review comments > > * Added tags > > * Based on -rc2 > > > >Patches are also pushed here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > > > >Feedback and testing welcome. At this point, I'd like to start thinking > >about getting this merged for 4.16. > > > > You can add > > Tested-by: Laura Abbott <labbott@redhat.com> Thanks, Laura! Will
On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: > Patches are also pushed here: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > > Feedback and testing welcome. At this point, I'd like to start thinking > about getting this merged for 4.16. For the record, the fixed up version was pushed by Will here: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti and I queued it for 4.16 in the arm64 for-next/core branch (same tree as above). -- Catalin
On 12/11/2017 09:59 AM, Catalin Marinas wrote: > On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: >> Patches are also pushed here: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti >> >> Feedback and testing welcome. At this point, I'd like to start thinking >> about getting this merged for 4.16. > > For the record, the fixed up version was pushed by Will here: > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti > > and I queued it for 4.16 in the arm64 for-next/core branch (same tree as > above). Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there a plan to get the ARM64/KPTI patches backported towards stable trees as well? Thanks! -- Florian
On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: > On 12/11/2017 09:59 AM, Catalin Marinas wrote: > > On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: > >> Patches are also pushed here: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > >> > >> Feedback and testing welcome. At this point, I'd like to start thinking > >> about getting this merged for 4.16. > > > > For the record, the fixed up version was pushed by Will here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti > > > > and I queued it for 4.16 in the arm64 for-next/core branch (same tree as > > above). > > Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there > a plan to get the ARM64/KPTI patches backported towards stable trees as > well? Stable tree patches have to get into Linus's tree first before I can do anything :) Anyway, once that happens, yes, there is a plan, but it's a bit "different", and I'll talk about it once these are merged. thanks, greg k-h
On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote: > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: >> On 12/11/2017 09:59 AM, Catalin Marinas wrote: >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: >>>> Patches are also pushed here: >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti >>>> >>>> Feedback and testing welcome. At this point, I'd like to start thinking >>>> about getting this merged for 4.16. >>> >>> For the record, the fixed up version was pushed by Will here: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti >>> >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as >>> above). >> >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there >> a plan to get the ARM64/KPTI patches backported towards stable trees as >> well? > > Stable tree patches have to get into Linus's tree first before I can do > anything :) > > Anyway, once that happens, yes, there is a plan, but it's a bit > "different", and I'll talk about it once these are merged. Great, thanks! Bonus question, if someone is using any of the affected devices in AArch32, should we be expecting to see ARM/Linux changes as well, that is, is there a plan to come up with a kpti implementation for ARM? -- Florian
On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: > Great, thanks! Bonus question, if someone is using any of the affected > devices in AArch32, should we be expecting to see ARM/Linux changes as > well, that is, is there a plan to come up with a kpti implementation for > ARM? Given what little information there is, I've been trying today to see whether I can detect whether a userspace address is cached or uncached - the results suggest that I have code that works with an error rate of between 2 and 20 in 10000 in a 32-bit VM on Cortex A72. Whether that translates to Cortex A15, I don't know yet - I need a working Cortex A15 platform for that. Unfortunately, my only Cortex A15 platform does not setup the architected timer, and so the kernel doesn't make it available to userspace. I will be raising this with those concerned on Monday, in the hope of getting it resolved. Based on this and the information on developer.arm.com, my gut feeling is that 32-bit kernels running on a CPU with an architected timer _or_ with some other high resolution timer available to non-privileged userspace are likely to be vulnerable in some way, as it seems to be possible to measure whether a specific load results in data being sourced from the cache or from memory. That all said, what I read about Chrome OS is that google believes that isn't exploitable - which seems to be a contradiction to the information ARM have published. I'm not sure what the reasoning is there, maybe there's just no current working exploit yet. So, the message to take away is that 32-bit kernels are rather behind on this issue, there are no known patches in development, and it is not really known whether there is an exploitable problem for 32-bit kernels or not. Not really where I'd like 32-bit kernels to be. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up
On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: > On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote: > > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: > >> On 12/11/2017 09:59 AM, Catalin Marinas wrote: > >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: > >>>> Patches are also pushed here: > >>>> > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti > >>>> > >>>> Feedback and testing welcome. At this point, I'd like to start thinking > >>>> about getting this merged for 4.16. > >>> > >>> For the record, the fixed up version was pushed by Will here: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti > >>> > >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as > >>> above). > >> > >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there > >> a plan to get the ARM64/KPTI patches backported towards stable trees as > >> well? > > > > Stable tree patches have to get into Linus's tree first before I can do > > anything :) > > > > Anyway, once that happens, yes, there is a plan, but it's a bit > > "different", and I'll talk about it once these are merged. > > Great, thanks! Bonus question, if someone is using any of the affected > devices in AArch32, should we be expecting to see ARM/Linux changes as > well, that is, is there a plan to come up with a kpti implementation for > ARM? I have not heard of anyone working on this for any arm32 platforms, as of this time, sorry. Which makes me worry about my android tv, glad I don't connect it to the network :( thanks, greg k-h
On 5 January 2018 at 16:06, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote: >> On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote: >> > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote: >> >> On 12/11/2017 09:59 AM, Catalin Marinas wrote: >> >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote: >> >>>> Patches are also pushed here: >> >>>> >> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti >> >>>> >> >>>> Feedback and testing welcome. At this point, I'd like to start thinking >> >>>> about getting this merged for 4.16. >> >>> >> >>> For the record, the fixed up version was pushed by Will here: >> >>> >> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti >> >>> >> >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as >> >>> above). >> >> >> >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there >> >> a plan to get the ARM64/KPTI patches backported towards stable trees as >> >> well? >> > >> > Stable tree patches have to get into Linus's tree first before I can do >> > anything :) >> > >> > Anyway, once that happens, yes, there is a plan, but it's a bit >> > "different", and I'll talk about it once these are merged. >> >> Great, thanks! Bonus question, if someone is using any of the affected >> devices in AArch32, should we be expecting to see ARM/Linux changes as >> well, that is, is there a plan to come up with a kpti implementation for >> ARM? > > I have not heard of anyone working on this for any arm32 platforms, > as of this time, sorry. > > Which makes me worry about my android tv, glad I don't connect it to the > network :( > The only ARM variant that is currently known to be affected by Meltdown/variant 3 (which is what KPTI addresses) is the Cortex-A75, which is a 64-bit core. That still means 32-bit guests running under KVM will be affected, as well as a 32-bit kernel running on the bare metal, but in practice, 32-bit ARM simply doesn't need KPTI. (My KASLR patches for ARM are a bit in limbo atm, but those would benefit from unmapping the kernel while running in userland as well) As for variants 1/2 aka Spectre, I suppose ARM will need to implement the same nospec/retpoline primitives that are being proposed for other arches, but that work is not as fleshed out yet.
Hi everybody, This is version three of the patches formerly known as KAISER (♔). v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/542751.html v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-November/544817.html Changes since v2 include: * Rename command-line option from "kaiser=" to "kpti=" for parity with x86 * Fixed Falkor erratum workaround (missing '~') * Moved vectors base from literal pool into separate data page * Added TTBR_ASID_MASK instead of open-coded constants * Added missing newline to error message * Fail to probe SPE if KPTI is enabled * Addressed minor review comments * Added tags * Based on -rc2 Patches are also pushed here: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti Feedback and testing welcome. At this point, I'd like to start thinking about getting this merged for 4.16. Cheers, Will --->8 Will Deacon (20): arm64: mm: Use non-global mappings for kernel space arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN arm64: mm: Move ASID from TTBR0 to TTBR1 arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 arm64: mm: Rename post_ttbr0_update_workaround arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN arm64: mm: Allocate ASIDs in pairs arm64: mm: Add arm64_kernel_unmapped_at_el0 helper arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI arm64: entry: Add exception trampoline page for exceptions from EL0 arm64: mm: Map entry trampoline into trampoline and kernel page tables arm64: entry: Explicitly pass exception level to kernel_ventry macro arm64: entry: Hook up entry trampoline to exception vectors arm64: erratum: Work around Falkor erratum #E1003 in trampoline code arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0() arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR arm64: kaslr: Put kernel vectors address in separate data page arch/arm64/Kconfig | 30 +++-- arch/arm64/include/asm/asm-uaccess.h | 26 ++-- arch/arm64/include/asm/assembler.h | 27 +---- arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/fixmap.h | 5 + arch/arm64/include/asm/kernel-pgtable.h | 12 +- arch/arm64/include/asm/mmu.h | 11 ++ arch/arm64/include/asm/mmu_context.h | 9 +- arch/arm64/include/asm/pgtable-hwdef.h | 1 + arch/arm64/include/asm/pgtable-prot.h | 21 +++- arch/arm64/include/asm/pgtable.h | 1 + arch/arm64/include/asm/proc-fns.h | 6 - arch/arm64/include/asm/tlbflush.h | 16 ++- arch/arm64/include/asm/uaccess.h | 21 +++- arch/arm64/kernel/asm-offsets.c | 6 +- arch/arm64/kernel/cpufeature.c | 41 +++++++ arch/arm64/kernel/entry.S | 203 +++++++++++++++++++++++++++----- arch/arm64/kernel/process.c | 12 +- arch/arm64/kernel/vmlinux.lds.S | 40 ++++++- arch/arm64/lib/clear_user.S | 2 +- arch/arm64/lib/copy_from_user.S | 2 +- arch/arm64/lib/copy_in_user.S | 2 +- arch/arm64/lib/copy_to_user.S | 2 +- arch/arm64/mm/cache.S | 2 +- arch/arm64/mm/context.c | 36 +++--- arch/arm64/mm/mmu.c | 31 +++++ arch/arm64/mm/proc.S | 12 +- arch/arm64/xen/hypercall.S | 2 +- drivers/perf/arm_spe_pmu.c | 9 ++ 29 files changed, 454 insertions(+), 137 deletions(-) -- 2.1.4