linux-kernel - Re: [PATCH 2/3] arm64: Work around Falkor erratum 1003

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, 8 Dec 2016 10:31:16 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Christopher Covington <cov@...eaurora.org>
Cc:     Will Deacon <will.deacon@....com>,
        Shanker Donthineni <shankerd@...eaurora.org>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Andre Przywara <andre.przywara@....com>,
        Ganapatrao Kulkarni <gkulkarni@...iumnetworks.com>,
        James Morse <james.morse@....com>,
        Andrew Pinski <apinski@...ium.com>,
        Mark Rutland <mark.rutland@....com>,
        Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Geoff Levand <geoff@...radead.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] arm64: Work around Falkor erratum 1003

On Wed, Dec 07, 2016 at 03:00:26PM -0500, Christopher Covington wrote:
> From: Shanker Donthineni <shankerd@...eaurora.org>
> 
> On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
> allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
> updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
> separately using a reserved ASID will ensure that there are no TLB entries
> with incorrect ASID after changing the the ASID.
> 
> Pseudo code:
>   write TTBRx_EL1[ASID] to a reserved value
>   ISB
>   write TTBRx_EL1[BADDR] to a desired value
>   ISB
>   write TTBRx_EL1[ASID] to a desired value
>   ISB

While the new ASID probably won't have incorrect TLB entries, the
reserved ASID will have random entries from all over the place. That's
because in step 1 you change the ASID to the reserved one while leaving
the old BADDR in place. There is a brief time before changing the ASID
when speculative page table walks will populate the TLB with entries
tagged with the reserved ASID. Such entries are never removed during TLB
shoot-down for the real ASID, so, depending on how this CPU implements
the walk cache, you could end up with intermediate level entries still
active and pointing to freed/reused pages. It will eventually hit an
entry that looks global with weird consequences.

We've been bitten by this in the past on arm32: 52af9c6cd863 ("ARM:
6943/1: mm: use TTBR1 instead of reserved context ID").

-- 
Catalin