lkml.org 
[lkml]   [2016]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)
    From
    Date
    On 04/27/2016 09:39 AM, Andy Lutomirski wrote:
    > On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky <thomas.lendacky@amd.com> 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?

    The AES crypto uses a tweak such that two identical plaintexts at
    different locations will have different ciphertext. So swapping the
    ciphertext of two pages will not result in the plaintext being swapped.

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

    For SEV mode, relocating a physical backing page takes extra steps.
    There are APIs that are used to have the AMD Secure Processor create a
    transportable encrypted page that can then be moved to a new location
    in memory. After moving it to the new location the APIs are used to
    haves the AMD Secure Processor re-encrypt the page for use with the
    guests SEV key. Based on #1 above, just moving a page without invoking
    the necessary APIs will result in the decryption returning garbage.

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

    There is nothing that prevents resuming a guest with the wrong ASID.
    This relies on the resulting corruption of the guest code/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?

    In SEV mode, the caches are tagged with the ASID. So if you try to read
    a cached page with a different ASID, it would result in a cache miss
    for that ASID and will instead fetch from memory and decrypt using
    the that ASID's key.

    Thanks,
    Tom

    >
    > --Andy
    >

    \
     
     \ /
      Last update: 2016-04-27 22:21    [W:4.179 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site