From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
mark.rutland@arm.com, keescook@chromium.org,
ard.biesheuvel@linaro.org,
Catalin Marinas <catalin.marinas@arm.com>,
dave.hansen@linux.intel.com, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, msalter@redhat.com,
tglx@linutronix.de, labbott@redhat.com, sboyd@codeaurora.org,
linux-arm-kernel@lists.infradead.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
Date: Thu, 4 Jan 2018 23:27:23 +0000 [thread overview]
Message-ID: <20180104232722.GB17719@n2100.armlinux.org.uk> (raw)
In-Reply-To: <092a51ec-f856-2b51-5d47-8acbdc671031@gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
Date: Thu, 4 Jan 2018 23:27:23 +0000 [thread overview]
Message-ID: <20180104232722.GB17719@n2100.armlinux.org.uk> (raw)
In-Reply-To: <092a51ec-f856-2b51-5d47-8acbdc671031@gmail.com>
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
next prev parent reply other threads:[~2018-01-04 23:27 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 12:35 [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI) Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 01/20] arm64: mm: Use non-global mappings for kernel space Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 02/20] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 03/20] arm64: mm: Move ASID from TTBR0 to TTBR1 Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 04/20] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003 Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 05/20] arm64: mm: Rename post_ttbr0_update_workaround Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 06/20] arm64: mm: Fix and re-enable ARM64_SW_TTBR0_PAN Will Deacon
2017-12-06 12:35 ` Will Deacon
2018-01-17 2:58 ` Yisheng Xie
2018-01-17 2:58 ` Yisheng Xie
2017-12-06 12:35 ` [PATCH v3 07/20] arm64: mm: Allocate ASIDs in pairs Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 08/20] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 09/20] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 10/20] arm64: entry: Add exception trampoline page for exceptions from EL0 Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 11/20] arm64: mm: Map entry trampoline into trampoline and kernel page tables Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 14:32 ` Mark Rutland
2017-12-06 14:32 ` Mark Rutland
2018-01-23 8:28 ` Yisheng Xie
2018-01-23 8:28 ` Yisheng Xie
2018-01-23 10:04 ` Will Deacon
2018-01-23 10:04 ` Will Deacon
2018-01-23 10:43 ` Yisheng Xie
2018-01-23 10:43 ` Yisheng Xie
2017-12-06 12:35 ` [PATCH v3 12/20] arm64: entry: Explicitly pass exception level to kernel_ventry macro Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 13/20] arm64: entry: Hook up entry trampoline to exception vectors Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 14/20] arm64: erratum: Work around Falkor erratum #E1003 in trampoline code Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 15/20] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 16/20] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 14:11 ` Mark Rutland
2017-12-06 14:11 ` Mark Rutland
2017-12-06 12:35 ` [PATCH v3 17/20] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:35 ` [PATCH v3 18/20] perf: arm_spe: Fail device probe when arm64_kernel_unmapped_at_el0() Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 13:34 ` Mark Rutland
2017-12-06 13:34 ` Mark Rutland
2017-12-06 12:35 ` [PATCH v3 19/20] arm64: mm: Introduce TTBR_ASID_MASK for getting at the ASID in the TTBR Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 14:12 ` Mark Rutland
2017-12-06 14:12 ` Mark Rutland
2017-12-06 12:35 ` [PATCH v3 20/20] arm64: kaslr: Put kernel vectors address in separate data page Will Deacon
2017-12-06 12:35 ` Will Deacon
2017-12-06 12:59 ` Ard Biesheuvel
2017-12-06 12:59 ` Ard Biesheuvel
2017-12-06 13:27 ` Will Deacon
2017-12-06 13:27 ` Will Deacon
2017-12-06 14:03 ` Ard Biesheuvel
2017-12-06 14:03 ` Ard Biesheuvel
2017-12-08 0:40 ` [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI) Laura Abbott
2017-12-08 0:40 ` Laura Abbott
2017-12-11 13:23 ` Will Deacon
2017-12-11 13:23 ` Will Deacon
2017-12-11 17:59 ` Catalin Marinas
2017-12-11 17:59 ` Catalin Marinas
2018-01-04 5:17 ` Florian Fainelli
2018-01-04 5:17 ` Florian Fainelli
2018-01-04 6:50 ` Greg Kroah-Hartman
2018-01-04 6:50 ` Greg Kroah-Hartman
2018-01-04 18:23 ` Florian Fainelli
2018-01-04 18:23 ` Florian Fainelli
2018-01-04 23:27 ` Russell King - ARM Linux [this message]
2018-01-04 23:27 ` Russell King - ARM Linux
2018-01-05 16:06 ` Greg Kroah-Hartman
2018-01-05 16:06 ` Greg Kroah-Hartman
2018-01-05 16:12 ` Ard Biesheuvel
2018-01-05 16:12 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180104232722.GB17719@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=msalter@redhat.com \
--cc=sboyd@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.