On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > This RFC patch series provides support for AMD's new Secure Memory > Encryption (SME) feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be automatically > decrypted when read from DRAM and will be automatically encrypted when > written to DRAM. Details on SME can found in the links below. Having read through the docs briefly, some questions: 1. How does the crypto work? Is it straight AES-ECB? Is it a tweakable mode? If so, what does into the tweak? For example, if I swap the ciphertext of two pages, does the plaintext of the pages get swapped? If not, why not? 2. In SEV mode, how does the hypervisor relocate a physical backing page? Does it simple move it and update the 2nd-level page tables? If so, is the result of decryption guaranteed to be garbage if it relocates a page and re-inserts it at the wrong guest physical address? 3. In SEV mode, does anything prevent the hypervisor from resuming a guest with the wrong ASID, or is this all relying on the resulting corruption of the guest code and data to cause a crash? 4. As I understand it, the caches are all unencrypted, and they're tagged with the physical address, *including* the SME bit (bit 47). In SEV mode, are they also tagged with the ASID? I.e. if I have a page in cache for ASID 1 and I try to read it with ASID 2, will I get a fresh copy decrypted with ASID 2's key? If so, will the old ASID 1 copy be evicted, or will it stay in cache and be non-coherent? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
