Re: [Qemu-devel] [RFC PATCH v1 06/22] sev: add initial SEV support

[Brijesh Singh <brijesh.singh@amd.com>]

Hi Michael,

>>
>> Yes policy is described in chapter 3, page 23. I am open to separate the
>> fields.
>> Let me know if something like this works
>>
>> sev-launch-rule,flags.ks=0,policy.dbg=0,policy.ks=0,policy.nosend=0,...
>
> My question is, does all of it have to be sev specific?
> For example, add a generic flag to block debug commands from monitor.
> When blocked, and if sev happens to be enabled, you can run guest with
> debug disabled.
>
>
All the sev option should be specified during guest creation.

A typical SEV flow look like this:

1) Guest owner requests cloud provider to launch a SEV quest.

2) Cloud provides requests the guest owner to provide the SEV launch 
parameter. These parameters includes: flags, policy, nonce, public 
diffie-hellman keys.

3) cloud provider launches qemu with '-sev' option.
    The code path looks like this:

    kvm_sev_guest_start()   [qemu]
       kvm_vm_ioctl(SEV_ISSUE_CMD)                 [kvm]
         asid = allocates a new SEV aid.           [kvm]
         psp_issue_cmd(LAUNCH_START)               [kvm]
          // the will call the firmware to create
          // new cryptographic context
         psp_issue_cmd(ACTIVATE, asid)             [kvm]
         // the command will bind asid to this crypto
         // context and loads the encryption key into
         // memory controller

4) As part of guest creation qemu loader copies data/code into guest 
memory (e.g BIOS). We need to encrypt the data/code copied into guest 
memory using LAUNCH_UPDATE command.
       sev_launch_update()
         kvm_vm_ioctl(SEV_ISSUE_CMD)
           psp_issue_cmd(LAUNCH_UPDATE, buffer)
            // the command will encrypt in-place

5) After qemu is done copying data into guest memory we call 
LAUNCH_FINISH, this command generate a measurement (basically hash of 
the data encrypted through LAUNCH_UPDATE).

6) Cloud provider sends the measurement to guest owner.

7) Guest owner validates the measurement. If measurement matches then we 
are good to launch the guest. This should ensure that bootcode was not 
compromised by hypervisor.

Once the guest is running then memory content of VM is transparently 
encrypted with key loaded into memory controller. SEV guest have the 
concept of private and shared memory. Private memory is encrypted with 
the guest-specific keys, while share memory may be encrypted with 
hypervisor key. Certain type of memory (namely instruction pages and 
guest page tables) are always considered as private. The guest OS can
mark individual pages of memory as encrypted using the standard x86 page 
table. I call it C-bit in PTE, if C-bit (bit 47) is set then page is 
private and if C-bit is 0 then page is shared. A page that is marked 
private will be automatically decrypted when read from the DRAM and 
encrypted when written to DRAM. Note that since C-bit is only 
controllable by the guest OS when it in operating in 64-bit or 32-bit 
PAE mode, in all other modes the SEV hardware forces the C-bit to a 1.

One of field in launch_start struct is 'policy', if policy allows the 
debugging then hypervisor can use SEV commands 
(kvm_sev_debug_decrypt/kvm_sev_debug_encrypt) to read and write into 
guest memory. If policy does not allow the debugging then any read of 
guest memory from hypervisor will get encrypted data and similarly 
writes to guest memory from hypervisor will result guest reading the 
garbage.