linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 16 May 2020 12:35:18 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Rik van Riel <riel@...riel.com>
Cc:     linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org
Subject: Re: Possibility of conflicting memory types in lazier TLB mode?

Excerpts from Rik van Riel's message of May 16, 2020 5:24 am:
> On Fri, 2020-05-15 at 16:50 +1000, Nicholas Piggin wrote:
>> 
>> 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?
> 
> On x86, all stores become visible in-order globally.
> 
> I suspect that
> means any pending stores in the queue
> would become visible to the rest of the system before
> the store to the "current" cpu-local variable, as
> well as other writes from the context switch code
> become visible to the rest of the system.
> 
> Is that too naive a way of preventing the scenario you
> describe?
> 
> What am I overlooking?

I'm concerned if the physical address gets mapped with different 
cacheability attributes where that ordering is not enforced by cache 
coherency

 "The PAT allows any memory type to be specified in the page tables, and 
 therefore it is possible to have a single physical page mapped to two 
 or more different linear addresses, each with different memory types. 
 Intel does not support this practice because it may lead to undefined 
 operations that can result in a system failure. In particular, a WC 
 page must never be aliased to a cacheable page because WC writes may 
 not check the processor caches." -- Vol. 3A 11-35

Maybe I'm over thinking it, and this would never happen anyway because 
if anyone were to map a RAM page WC, they might always have to ensure 
all processor caches are flushed first anyway so perhaps this is just a 
non-issue?

Thanks,
Nick