linux-kernel - Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Jan 2018 23:27:23 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        mark.rutland@....com, keescook@...omium.org,
        ard.biesheuvel@...aro.org,
        Catalin Marinas <catalin.marinas@....com>,
        dave.hansen@...ux.intel.com, Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, msalter@...hat.com,
        tglx@...utronix.de, labbott@...hat.com, sboyd@...eaurora.org,
        linux-arm-kernel@...ts.infradead.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3 00/20] arm64: Unmap the kernel whilst running in
 userspace (KPTI)

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