| Message ID | 0e2b3d80e3d61b121ff4b508e5299e3c23f7b090.1628076205.git.ashish.kalra@amd.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add SEV guest live migration support | expand |
On 04/08/2021 14:53, Ashish Kalra wrote: > From: Brijesh Singh <brijesh.singh@amd.com> > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> > --- > docs/amd-memory-encryption.txt | 46 +++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > index 12ca25180e..0d9184532a 100644 > --- a/docs/amd-memory-encryption.txt > +++ b/docs/amd-memory-encryption.txt > @@ -126,7 +126,51 @@ TODO > > Live Migration > ---------------- > -TODO > +AMD SEV encrypts the memory of VMs and because a different key is used > +in each VM, the hypervisor will be unable to simply copy the > +ciphertext from one VM to another to migrate the VM. Instead the AMD SEV Key > +Management API provides sets of function which the hypervisor can use > +to package a guest page for migration, while maintaining the confidentiality > +provided by AMD SEV. > + > +SEV guest VMs have the concept of private and shared memory. The private > +memory is encrypted with the guest-specific key, while shared memory may > +be encrypted with the hypervisor key. The migration APIs provided by the > +SEV API spec should be used for migrating the private pages. > + > +The KVM_HC_MAP_GPA_RANGE hypercall is used by the SEV guest to notify a > +change in the page encryption status to the hypervisor. The hypercall > +is invoked when the encryption attribute is changed from encrypted -> decrypted > +and vice versa. By default all guest pages are considered encrypted. > + > +This hypercall exits to qemu via KVM_EXIT_HYPERCALL to manage the guest > +shared regions and integrate with the qemu's migration code. The shared > +region list can be used to check if the given guest page is private or shared. > + > +Before initiating the migration, we need to know the targets machine's public s/targets/target/ > +Diffie-Hellman key (PDH) and certificate chain. It can be retrieved > +with the 'query-sev-capabilities' QMP command or using the sev-tool. The > +migrate-set-parameter can be used to pass the target machine's PDH and > +certificate chain. It's better to clarify that you use query-sev-capabilities QMP command on the *target* VM (to get its PDF and cert) when it's ready, and then use migrate-set-parameter QMP command on the *source* so it can prepare the migration for that specific target. > + > +During the migration flow, the SEND_START is called on the source hypervisor > +to create an outgoing encryption context. The SEV guest policy dictates whether > +the certificate passed through the migrate-sev-set-info command will be Here you say migrate-sev-set-info but above you said migrate-set-parameter. Which one is it? -Dov > +validated. SEND_UPDATE_DATA is called to encrypt the guest private pages. > +After migration is completed, SEND_FINISH is called to destroy the encryption > +context and make the VM non-runnable to protect it against cloning. > + > +On the target machine, RECEIVE_START is called first to create an > +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy > +the received encrypted page into guest memory. After migration has > +completed, RECEIVE_FINISH is called to make the VM runnable. > + > +For more information about the migration see SEV API Appendix A > +Usage flow (Live migration section). > + > +NOTE: > +To protect against the memory clone SEV APIs are designed to make the VM > +unrunnable in case of the migration failure. > > References > ----------------- >
Hello Dov, On Thu, Aug 05, 2021 at 09:34:42AM +0300, Dov Murik wrote: > > > On 04/08/2021 14:53, Ashish Kalra wrote: > > From: Brijesh Singh <brijesh.singh@amd.com> > > > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> > > --- > > docs/amd-memory-encryption.txt | 46 +++++++++++++++++++++++++++++++++- > > 1 file changed, 45 insertions(+), 1 deletion(-) > > > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > > index 12ca25180e..0d9184532a 100644 > > --- a/docs/amd-memory-encryption.txt > > +++ b/docs/amd-memory-encryption.txt > > @@ -126,7 +126,51 @@ TODO > > > > Live Migration > > ---------------- > > -TODO > > +AMD SEV encrypts the memory of VMs and because a different key is used > > +in each VM, the hypervisor will be unable to simply copy the > > +ciphertext from one VM to another to migrate the VM. Instead the AMD SEV Key > > +Management API provides sets of function which the hypervisor can use > > +to package a guest page for migration, while maintaining the confidentiality > > +provided by AMD SEV. > > + > > +SEV guest VMs have the concept of private and shared memory. The private > > +memory is encrypted with the guest-specific key, while shared memory may > > +be encrypted with the hypervisor key. The migration APIs provided by the > > +SEV API spec should be used for migrating the private pages. > > + > > +The KVM_HC_MAP_GPA_RANGE hypercall is used by the SEV guest to notify a > > +change in the page encryption status to the hypervisor. The hypercall > > +is invoked when the encryption attribute is changed from encrypted -> decrypted > > +and vice versa. By default all guest pages are considered encrypted. > > + > > +This hypercall exits to qemu via KVM_EXIT_HYPERCALL to manage the guest > > +shared regions and integrate with the qemu's migration code. The shared > > +region list can be used to check if the given guest page is private or shared. > > + > > +Before initiating the migration, we need to know the targets machine's public > > s/targets/target/ > > > +Diffie-Hellman key (PDH) and certificate chain. It can be retrieved > > +with the 'query-sev-capabilities' QMP command or using the sev-tool. The > > +migrate-set-parameter can be used to pass the target machine's PDH and > > +certificate chain. > > It's better to clarify that you use query-sev-capabilities QMP command > on the *target* VM (to get its PDF and cert) when it's ready, and then > use migrate-set-parameter QMP command on the *source* so it can prepare > the migration for that specific target. > > Ok. > > + > > +During the migration flow, the SEND_START is called on the source hypervisor > > +to create an outgoing encryption context. The SEV guest policy dictates whether > > +the certificate passed through the migrate-sev-set-info command will be > > Here you say migrate-sev-set-info but above you said > migrate-set-parameter. Which one is it? > > Actually earlier it used to be migrate-sev-set-info, so this is a typo, it should be migrate-set-parameter. Thanks, Ashish > > > +validated. SEND_UPDATE_DATA is called to encrypt the guest private pages. > > +After migration is completed, SEND_FINISH is called to destroy the encryption > > +context and make the VM non-runnable to protect it against cloning. > > + > > +On the target machine, RECEIVE_START is called first to create an > > +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy > > +the received encrypted page into guest memory. After migration has > > +completed, RECEIVE_FINISH is called to make the VM runnable. > > + > > +For more information about the migration see SEV API Appendix A > > +Usage flow (Live migration section). > > + > > +NOTE: > > +To protect against the memory clone SEV APIs are designed to make the VM > > +unrunnable in case of the migration failure. > > > > References > > ----------------- > >
On Wed, Aug 04, 2021 at 11:53:47AM +0000, Ashish Kalra wrote: > From: Brijesh Singh <brijesh.singh@amd.com> > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> > --- > docs/amd-memory-encryption.txt | 46 +++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > index 12ca25180e..0d9184532a 100644 > --- a/docs/amd-memory-encryption.txt > +++ b/docs/amd-memory-encryption.txt > @@ -126,7 +126,51 @@ TODO > > Live Migration > ---------------- > +NOTE: > +To protect against the memory clone SEV APIs are designed to make the VM > +unrunnable in case of the migration failure. Can you expand on this, as the limited explanation does not make a whole lot of sense. What is the threat model here, what actions are being taken to ensure unrunnability and who or what enforces that ? Which VM is this referring to - the src VM or dst VM ? I comes across like you're trying to protect against the case where the same VM is executing on both hosts concurrently, but I'm not clear how that ties into migration failure. Regards, Daniel
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt index 12ca25180e..0d9184532a 100644 --- a/docs/amd-memory-encryption.txt +++ b/docs/amd-memory-encryption.txt @@ -126,7 +126,51 @@ TODO Live Migration ---------------- -TODO +AMD SEV encrypts the memory of VMs and because a different key is used +in each VM, the hypervisor will be unable to simply copy the +ciphertext from one VM to another to migrate the VM. Instead the AMD SEV Key +Management API provides sets of function which the hypervisor can use +to package a guest page for migration, while maintaining the confidentiality +provided by AMD SEV. + +SEV guest VMs have the concept of private and shared memory. The private +memory is encrypted with the guest-specific key, while shared memory may +be encrypted with the hypervisor key. The migration APIs provided by the +SEV API spec should be used for migrating the private pages. + +The KVM_HC_MAP_GPA_RANGE hypercall is used by the SEV guest to notify a +change in the page encryption status to the hypervisor. The hypercall +is invoked when the encryption attribute is changed from encrypted -> decrypted +and vice versa. By default all guest pages are considered encrypted. + +This hypercall exits to qemu via KVM_EXIT_HYPERCALL to manage the guest +shared regions and integrate with the qemu's migration code. The shared +region list can be used to check if the given guest page is private or shared. + +Before initiating the migration, we need to know the targets machine's public +Diffie-Hellman key (PDH) and certificate chain. It can be retrieved +with the 'query-sev-capabilities' QMP command or using the sev-tool. The +migrate-set-parameter can be used to pass the target machine's PDH and +certificate chain. + +During the migration flow, the SEND_START is called on the source hypervisor +to create an outgoing encryption context. The SEV guest policy dictates whether +the certificate passed through the migrate-sev-set-info command will be +validated. SEND_UPDATE_DATA is called to encrypt the guest private pages. +After migration is completed, SEND_FINISH is called to destroy the encryption +context and make the VM non-runnable to protect it against cloning. + +On the target machine, RECEIVE_START is called first to create an +incoming encryption context. The RECEIVE_UPDATE_DATA is called to copy +the received encrypted page into guest memory. After migration has +completed, RECEIVE_FINISH is called to make the VM runnable. + +For more information about the migration see SEV API Appendix A +Usage flow (Live migration section). + +NOTE: +To protect against the memory clone SEV APIs are designed to make the VM +unrunnable in case of the migration failure. References -----------------