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