linux-kernel - Possibility of conflicting memory types in lazier TLB mode?

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-next>] [day] [month] [year] [list]

Message-Id: <1589523957.s4pf3vd48l.astroid@bobo.none>
Date:   Fri, 15 May 2020 16:50:19 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Rik van Riel <riel@...riel.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Possibility of conflicting memory types in lazier TLB mode?

Hi Rik,

Commit 145f573b89a62 ("Make lazy TLB mode lazier").

A couple of questions here (and I don't know the x86 architecture too 
well let alone the ASID stuff, so bear with me). I'm assuming, and it 
appears to be in the x86 manual that you can't map the same physical 
page with conflicting memory types on different processors in general
(or in different ASIDs on the same processor?)

Firstly, the freed_tables check, that's to prevent CPUs in the lazy mode 
with this mm loaded in their ASID from bringing in new translations 
based on random "stuff" if they happen to speculatively load userspace 
addresses (but in lazy mode they would never explicitly load such 
addresses), right?

I'm guessing that's a problem but the changed pte case is not, is 
because the table walker is going to barf if it sees garbage, but a 
valid pte is okay.

Now the intel manual says conflicting attributes are bad because you'll 
lose cache coherency on stores. But the speculative accesses from the 
lazy thread will never push stores to cache coherency and result of the 
loads doesn't matter, so maybe that's how this special case avoids the
problem.

But what about if there are (real, not speculative) stores in the store 
queue still on the lazy thread from when it was switched, that have not 
yet become coherent? The page is freed by another CPU and reallocated
for something that maps it as nocache. Do you have a coherency problem 
there?

Ensuring the store queue is drained when switching to lazy seems like it 
would fix it, maybe context switch code does that already or you have 
some other trick or reason it's not a problem. Am I way off base here?

Thanks,
Nick