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.
