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  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

Powered by blists - more mailing lists