Thread (91 messages) 91 messages, 11 authors, 2018-12-13

Re: [RFC v2 00/13] Multi-Key Total Memory Encryption API (MKTME)

From: Dave Hansen <hidden>
Date: 2018-12-06 19:31:39
Also in: keyrings, linux-mm

On 12/6/18 11:10 AM, Andy Lutomirski wrote:
quoted
On Dec 6, 2018, at 7:39 AM, Dave Hansen [off-list ref] wrote:
The coherency is "fine" unless you have writeback of an older
cacheline that blows away newer data.  CPUs that support MKTME are
guaranteed to never do writeback of the lines that could be established
speculatively or from prefetching.
How is that sufficient?  Suppose I have some physical page mapped with
keys 1 and 2. #1 is logically live and I write to it.  Then I prefetch
or otherwise populate mapping 2 into the cache (in the S state,
presumably).  Now I clflush mapping 1 and read 2.  It contains garbage
in the cache, but the garbage in the cache is inconsistent with the
garbage in memory.  This can’t be a good thing, even if no writeback
occurs.

I suppose the right fix is to clflush the old mapping and then to zero
the new mapping.
Yep.  Practically, you need to write to the new mapping to give it any
meaning.  Those writes effectively blow away any previously cached,
garbage contents.

I think you're right, though, that the cached data might not be
_consistent_ with what is in memory.  It feels really dirty, but I can't
think of any problems that it actually causes.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help