| Message ID | 20210707183616.5620-25-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support | expand |
On Wed, Jul 07, 2021, Brijesh Singh wrote: > +static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd *argp) > +{ > + unsigned long npages, vaddr, vaddr_end, i, next_vaddr; > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > + struct sev_data_snp_launch_update data = {}; > + struct kvm_sev_snp_launch_update params; > + int *error = &argp->error; > + struct kvm_vcpu *vcpu; > + struct page **inpages; > + struct rmpupdate e; > + int ret; > + > + if (!sev_snp_guest(kvm)) > + return -ENOTTY; > + > + if (!sev->snp_context) > + return -EINVAL; > + > + if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, sizeof(params))) > + return -EFAULT; > + > + data.gctx_paddr = __psp_pa(sev->snp_context); > + > + /* Lock the user memory. */ > + inpages = sev_pin_memory(kvm, params.uaddr, params.len, &npages, 1); params.uaddr needs to be checked for validity, e.g. proper alignment. sev_pin_memory() does some checks, but not all checks. > + if (!inpages) > + return -ENOMEM; > + > + vcpu = kvm_get_vcpu(kvm, 0); > + vaddr = params.uaddr; > + vaddr_end = vaddr + params.len; > + > + for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i++) { > + unsigned long psize, pmask; > + int level = PG_LEVEL_4K; > + gpa_t gpa; > + > + if (!hva_to_gpa(kvm, vaddr, &gpa)) { I'm having a bit of deja vu... This flow needs to hold kvm->srcu to do a memslot lookup. That said, IMO having KVM do the hva->gpa is not a great ABI. The memslots are completely arbitrary (from a certain point of view) and have no impact on the validity of the memory pinning or PSP command. E.g. a memslot update while this code is in-flight would be all kinds of weird. In other words, make userspace provide both the hva (because it's sadly needed to pin memory) as well as the target gpa. That prevents KVM from having to deal with memslot lookups and also means that userspace can issue the command before configuring the memslots (though I've no idea if that's actually feasible for any userspace VMM). > + ret = -EINVAL; > + goto e_unpin; > + } > + > + psize = page_level_size(level); > + pmask = page_level_mask(level); Is there any hope of this path supporting 2mb/1gb pages in the not-too-distant future? If not, then I vote to do away with the indirection and just hardcode 4kg sizes in the flow. I.e. if this works on 4kb chunks, make that obvious. > + gpa = gpa & pmask; > + > + /* Transition the page state to pre-guest */ > + memset(&e, 0, sizeof(e)); > + e.assigned = 1; > + e.gpa = gpa; > + e.asid = sev_get_asid(kvm); > + e.immutable = true; > + e.pagesize = X86_TO_RMP_PG_LEVEL(level); > + ret = rmpupdate(inpages[i], &e); What happens if userspace pulls a stupid and assigns the same page to multiple SNP guests? Does RMPUPDATE fail? Can one RMPUPDATE overwrite another? > + if (ret) { > + ret = -EFAULT; > + goto e_unpin; > + } > + > + data.address = __sme_page_pa(inpages[i]); > + data.page_size = e.pagesize; > + data.page_type = params.page_type; > + data.vmpl3_perms = params.vmpl3_perms; > + data.vmpl2_perms = params.vmpl2_perms; > + data.vmpl1_perms = params.vmpl1_perms; > + ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_LAUNCH_UPDATE, &data, error); > + if (ret) { > + snp_page_reclaim(inpages[i], e.pagesize); > + goto e_unpin; > + } > + > + next_vaddr = (vaddr & pmask) + psize; > + } > + > +e_unpin: > + /* Content of memory is updated, mark pages dirty */ > + memset(&e, 0, sizeof(e)); > + for (i = 0; i < npages; i++) { > + set_page_dirty_lock(inpages[i]); > + mark_page_accessed(inpages[i]); > + > + /* > + * If its an error, then update RMP entry to change page ownership > + * to the hypervisor. > + */ > + if (ret) > + rmpupdate(inpages[i], &e); This feels wrong since it's purging _all_ RMP entries, not just those that were successfully modified. And maybe add a RMP "reset" helper, e.g. why is zeroing the RMP entry the correct behavior? > + } > + > + /* Unlock the user pages */ > + sev_unpin_memory(kvm, inpages, npages); > + > + return ret; > +} > +
On 7/16/21 3:01 PM, Sean Christopherson wrote: > On Wed, Jul 07, 2021, Brijesh Singh wrote: >> +static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd *argp) >> +{ >> + unsigned long npages, vaddr, vaddr_end, i, next_vaddr; >> + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; >> + struct sev_data_snp_launch_update data = {}; >> + struct kvm_sev_snp_launch_update params; >> + int *error = &argp->error; >> + struct kvm_vcpu *vcpu; >> + struct page **inpages; >> + struct rmpupdate e; >> + int ret; >> + >> + if (!sev_snp_guest(kvm)) >> + return -ENOTTY; >> + >> + if (!sev->snp_context) >> + return -EINVAL; >> + >> + if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, sizeof(params))) >> + return -EFAULT; >> + >> + data.gctx_paddr = __psp_pa(sev->snp_context); >> + >> + /* Lock the user memory. */ >> + inpages = sev_pin_memory(kvm, params.uaddr, params.len, &npages, 1); > params.uaddr needs to be checked for validity, e.g. proper alignment. > sev_pin_memory() does some checks, but not all checks. > Noted >> + if (!inpages) >> + return -ENOMEM; >> + >> + vcpu = kvm_get_vcpu(kvm, 0); >> + vaddr = params.uaddr; >> + vaddr_end = vaddr + params.len; >> + >> + for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i++) { >> + unsigned long psize, pmask; >> + int level = PG_LEVEL_4K; >> + gpa_t gpa; >> + >> + if (!hva_to_gpa(kvm, vaddr, &gpa)) { > I'm having a bit of deja vu... This flow needs to hold kvm->srcu to do a memslot > lookup. > > That said, IMO having KVM do the hva->gpa is not a great ABI. The memslots are > completely arbitrary (from a certain point of view) and have no impact on the > validity of the memory pinning or PSP command. E.g. a memslot update while this > code is in-flight would be all kinds of weird. > > In other words, make userspace provide both the hva (because it's sadly needed > to pin memory) as well as the target gpa. That prevents KVM from having to deal > with memslot lookups and also means that userspace can issue the command before > configuring the memslots (though I've no idea if that's actually feasible for > any userspace VMM). The operation happen during the guest creation time so I was not sure if memslot will be updated while we are executing this command. But I guess its possible that a VMM may run different thread which may update memslot while another thread calls the encryption. I'll let userspace provide both the HVA and GPA as you recommended. >> + ret = -EINVAL; >> + goto e_unpin; >> + } >> + >> + psize = page_level_size(level); >> + pmask = page_level_mask(level); > Is there any hope of this path supporting 2mb/1gb pages in the not-too-distant > future? If not, then I vote to do away with the indirection and just hardcode > 4kg sizes in the flow. I.e. if this works on 4kb chunks, make that obvious. No plans to do 1g/2mb in this path. I will make that obvious by hardcoding it. >> + gpa = gpa & pmask; >> + >> + /* Transition the page state to pre-guest */ >> + memset(&e, 0, sizeof(e)); >> + e.assigned = 1; >> + e.gpa = gpa; >> + e.asid = sev_get_asid(kvm); >> + e.immutable = true; >> + e.pagesize = X86_TO_RMP_PG_LEVEL(level); >> + ret = rmpupdate(inpages[i], &e); > What happens if userspace pulls a stupid and assigns the same page to multiple > SNP guests? Does RMPUPDATE fail? Can one RMPUPDATE overwrite another? The RMPUPDATE is available to the hv and it can call anytime with whatever it want. The important thing is the RMPUPDATE + PVALIDATE combination is what locks the page. In this case, PSP firmware updates the RMP table and also validates the page. If someone else attempts to issue another RMPUPDATE then Validated bit will be cleared and page is no longer used as a private. Access to unvalidated page will cause #VC. > >> + if (ret) { >> + ret = -EFAULT; >> + goto e_unpin; >> + } >> + >> + data.address = __sme_page_pa(inpages[i]); >> + data.page_size = e.pagesize; >> + data.page_type = params.page_type; >> + data.vmpl3_perms = params.vmpl3_perms; >> + data.vmpl2_perms = params.vmpl2_perms; >> + data.vmpl1_perms = params.vmpl1_perms; >> + ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_LAUNCH_UPDATE, &data, error); >> + if (ret) { >> + snp_page_reclaim(inpages[i], e.pagesize); >> + goto e_unpin; >> + } >> + >> + next_vaddr = (vaddr & pmask) + psize; >> + } >> + >> +e_unpin: >> + /* Content of memory is updated, mark pages dirty */ >> + memset(&e, 0, sizeof(e)); >> + for (i = 0; i < npages; i++) { >> + set_page_dirty_lock(inpages[i]); >> + mark_page_accessed(inpages[i]); >> + >> + /* >> + * If its an error, then update RMP entry to change page ownership >> + * to the hypervisor. >> + */ >> + if (ret) >> + rmpupdate(inpages[i], &e); > This feels wrong since it's purging _all_ RMP entries, not just those that were > successfully modified. And maybe add a RMP "reset" helper, e.g. why is zeroing > the RMP entry the correct behavior? By default all the pages are hypervior owned (i.e zero). If the LAUNCH_UPDATE was successful then page should have transition from the hypervisor owned to guest valid. By zero'ing it are reverting it back to hypevisor owned. I agree that I optimize it to clear the modified entries only and leave everything else as a default. thanks >> + } >> + >> + /* Unlock the user pages */ >> + sev_unpin_memory(kvm, inpages, npages); >> + >> + return ret; >> +} >> +
On Fri, Jul 16, 2021, Brijesh Singh wrote: > > On 7/16/21 3:01 PM, Sean Christopherson wrote: > > I'm having a bit of deja vu... This flow needs to hold kvm->srcu to do a memslot > > lookup. > > > > That said, IMO having KVM do the hva->gpa is not a great ABI. The memslots are > > completely arbitrary (from a certain point of view) and have no impact on the > > validity of the memory pinning or PSP command. E.g. a memslot update while this > > code is in-flight would be all kinds of weird. > > > > In other words, make userspace provide both the hva (because it's sadly needed > > to pin memory) as well as the target gpa. That prevents KVM from having to deal > > with memslot lookups and also means that userspace can issue the command before > > configuring the memslots (though I've no idea if that's actually feasible for > > any userspace VMM). > > The operation happen during the guest creation time so I was not sure if > memslot will be updated while we are executing this command. But I guess > its possible that a VMM may run different thread which may update > memslot while another thread calls the encryption. I'll let userspace > provide both the HVA and GPA as you recommended. I'm not worried about a well-behaved userspace VMM, I'm worried about the code KVM has to carry to guard against a misbehaving VMM. > >> + ret = -EINVAL; > >> + goto e_unpin; > >> + } > >> + > >> + psize = page_level_size(level); > >> + pmask = page_level_mask(level); > > Is there any hope of this path supporting 2mb/1gb pages in the not-too-distant > > future? If not, then I vote to do away with the indirection and just hardcode > > 4kg sizes in the flow. I.e. if this works on 4kb chunks, make that obvious. > > No plans to do 1g/2mb in this path. I will make that obvious by > hardcoding it. > > > >> + gpa = gpa & pmask; > >> + > >> + /* Transition the page state to pre-guest */ > >> + memset(&e, 0, sizeof(e)); > >> + e.assigned = 1; > >> + e.gpa = gpa; > >> + e.asid = sev_get_asid(kvm); > >> + e.immutable = true; > >> + e.pagesize = X86_TO_RMP_PG_LEVEL(level); > >> + ret = rmpupdate(inpages[i], &e); > > What happens if userspace pulls a stupid and assigns the same page to multiple > > SNP guests? Does RMPUPDATE fail? Can one RMPUPDATE overwrite another? > > The RMPUPDATE is available to the hv and it can call anytime with > whatever it want. The important thing is the RMPUPDATE + PVALIDATE > combination is what locks the page. In this case, PSP firmware updates > the RMP table and also validates the page. > > If someone else attempts to issue another RMPUPDATE then Validated bit > will be cleared and page is no longer used as a private. Access to > unvalidated page will cause #VC. Hmm, and there's no indication on success that the previous entry was assigned? Adding a tracepoint in rmpupdate() to allow tracking transitions is probably a good idea, otherwise debugging RMP violations and/or unexpected #VC is going to be painful. And/or if the kernel/KVM behavior is to never reassign directly and reading an RMP entry isn't prohibitively expensive, then we could add a sanity check that the RMP is unassigned and reject rmpupdate() if the page is already assigned. Probably not worth it if the overhead is noticeable, but it could be nice to have if things go sideways. > >> +e_unpin: > >> + /* Content of memory is updated, mark pages dirty */ > >> + memset(&e, 0, sizeof(e)); > >> + for (i = 0; i < npages; i++) { > >> + set_page_dirty_lock(inpages[i]); > >> + mark_page_accessed(inpages[i]); > >> + > >> + /* > >> + * If its an error, then update RMP entry to change page ownership > >> + * to the hypervisor. > >> + */ > >> + if (ret) > >> + rmpupdate(inpages[i], &e); > > This feels wrong since it's purging _all_ RMP entries, not just those that were > > successfully modified. And maybe add a RMP "reset" helper, e.g. why is zeroing > > the RMP entry the correct behavior? > > By default all the pages are hypervior owned (i.e zero). If the > LAUNCH_UPDATE was successful then page should have transition from the > hypervisor owned to guest valid. By zero'ing it are reverting it back to > hypevisor owned. > > I agree that I optimize it to clear the modified entries only and leave > everything else as a default. To be clear, it's not just an optimization. Pages that haven't yet been touched may be already owned by a different VM (or even this VM). I.e. "reverting" those pages would actually result in a form of corruption. It's somewhat of a moot point because assigning a single page to multiple guests is going to be fatal anyways, but potentially making a bug worse by introducing even more noise/confusion is not good.
On 7/19/21 3:51 PM, Sean Christopherson wrote: > > Hmm, and there's no indication on success that the previous entry was assigned? > Adding a tracepoint in rmpupdate() to allow tracking transitions is probably a > good idea, otherwise debugging RMP violations and/or unexpected #VC is going to > be painful. > Absolutely agree. It's in my TODO list for v5. I have been using my private debug patches with all those trace debug and will try to pull some of those in v5. > And/or if the kernel/KVM behavior is to never reassign directly and reading an RMP > entry isn't prohibitively expensive, then we could add a sanity check that the RMP > is unassigned and reject rmpupdate() if the page is already assigned. Probably > not worth it if the overhead is noticeable, but it could be nice to have if things > go sideways. > In later patches you see that during the page-state change, I do try to read RMP entry to detect some of these condition and warn user about them. The GHCB specification lets the hypervisor choose how it wants to handle the case in guest wanting to add the previously validated page. > > To be clear, it's not just an optimization. Pages that haven't yet been touched > may be already owned by a different VM (or even this VM). I.e. "reverting" those > pages would actually result in a form of corruption. It's somewhat of a moot point > because assigning a single page to multiple guests is going to be fatal anyways, > but potentially making a bug worse by introducing even more noise/confusion is not > good. > As you said, if a process is assigning the same page to multiple VMs then its fatal but I agree that we should do the right thing from the kernel ioctl handling. I will just clear the RMP entry for the pages which we touched. thanks
On 7/19/21 4:34 PM, Brijesh Singh wrote: > > > On 7/19/21 3:51 PM, Sean Christopherson wrote: >> >> Hmm, and there's no indication on success that the previous entry was >> assigned? I missed commenting on this. Yes, there is no hint that page was previously assigned or validated. thanks
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst index 8620383d405a..60ace54438c3 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/amd-memory-encryption.rst @@ -468,6 +468,34 @@ Returns: 0 on success, -negative on error See the SEV-SNP specification for further detail on the launch input. +20. KVM_SNP_LAUNCH_UPDATE +------------------------- + +The KVM_SNP_LAUNCH_UPDATE is used for encrypting a memory region. It also +calculates a measurement of the memory contents. The measurement is a signature +of the memory contents that can be sent to the guest owner as an attestation +that the memory was encrypted correctly by the firmware. + +Parameters (in): struct kvm_snp_launch_update + +Returns: 0 on success, -negative on error + +:: + + struct kvm_sev_snp_launch_update { + __u64 uaddr; /* userspace address need to be encrypted */ + __u32 len; /* length of memory region */ + __u8 imi_page; /* 1 if memory is part of the IMI */ + __u8 page_type; /* page type */ + __u8 vmpl3_perms; /* VMPL3 permission mask */ + __u8 vmpl2_perms; /* VMPL2 permission mask */ + __u8 vmpl1_perms; /* VMPL1 permission mask */ + }; + +See the SEV-SNP spec for further details on how to build the VMPL permission +mask and page type. + + References ========== diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c index f44a657e8912..1f0635ac9ff9 100644 --- a/arch/x86/kvm/svm/sev.c +++ b/arch/x86/kvm/svm/sev.c @@ -17,6 +17,7 @@ #include <linux/misc_cgroup.h> #include <linux/processor.h> #include <linux/trace_events.h> +#include <linux/sev.h> #include <asm/fpu/internal.h> #include <asm/trapnr.h> @@ -1624,6 +1625,144 @@ static int snp_launch_start(struct kvm *kvm, struct kvm_sev_cmd *argp) return rc; } +static struct kvm_memory_slot *hva_to_memslot(struct kvm *kvm, unsigned long hva) +{ + struct kvm_memslots *slots = kvm_memslots(kvm); + struct kvm_memory_slot *memslot; + + kvm_for_each_memslot(memslot, slots) { + if (hva >= memslot->userspace_addr && + hva < memslot->userspace_addr + (memslot->npages << PAGE_SHIFT)) + return memslot; + } + + return NULL; +} + +static bool hva_to_gpa(struct kvm *kvm, unsigned long hva, gpa_t *gpa) +{ + struct kvm_memory_slot *memslot; + gpa_t gpa_offset; + + memslot = hva_to_memslot(kvm, hva); + if (!memslot) + return false; + + gpa_offset = hva - memslot->userspace_addr; + *gpa = ((memslot->base_gfn << PAGE_SHIFT) + gpa_offset); + + return true; +} + +static int snp_page_reclaim(struct page *page, int rmppage_size) +{ + struct sev_data_snp_page_reclaim data = {}; + struct rmpupdate e = {}; + int rc, err; + + data.paddr = __sme_page_pa(page) | rmppage_size; + rc = snp_guest_page_reclaim(&data, &err); + if (rc) + return rc; + + return rmpupdate(page, &e); +} + +static int snp_launch_update(struct kvm *kvm, struct kvm_sev_cmd *argp) +{ + unsigned long npages, vaddr, vaddr_end, i, next_vaddr; + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; + struct sev_data_snp_launch_update data = {}; + struct kvm_sev_snp_launch_update params; + int *error = &argp->error; + struct kvm_vcpu *vcpu; + struct page **inpages; + struct rmpupdate e; + int ret; + + if (!sev_snp_guest(kvm)) + return -ENOTTY; + + if (!sev->snp_context) + return -EINVAL; + + if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, sizeof(params))) + return -EFAULT; + + data.gctx_paddr = __psp_pa(sev->snp_context); + + /* Lock the user memory. */ + inpages = sev_pin_memory(kvm, params.uaddr, params.len, &npages, 1); + if (!inpages) + return -ENOMEM; + + vcpu = kvm_get_vcpu(kvm, 0); + vaddr = params.uaddr; + vaddr_end = vaddr + params.len; + + for (i = 0; vaddr < vaddr_end; vaddr = next_vaddr, i++) { + unsigned long psize, pmask; + int level = PG_LEVEL_4K; + gpa_t gpa; + + if (!hva_to_gpa(kvm, vaddr, &gpa)) { + ret = -EINVAL; + goto e_unpin; + } + + psize = page_level_size(level); + pmask = page_level_mask(level); + gpa = gpa & pmask; + + /* Transition the page state to pre-guest */ + memset(&e, 0, sizeof(e)); + e.assigned = 1; + e.gpa = gpa; + e.asid = sev_get_asid(kvm); + e.immutable = true; + e.pagesize = X86_TO_RMP_PG_LEVEL(level); + ret = rmpupdate(inpages[i], &e); + if (ret) { + ret = -EFAULT; + goto e_unpin; + } + + data.address = __sme_page_pa(inpages[i]); + data.page_size = e.pagesize; + data.page_type = params.page_type; + data.vmpl3_perms = params.vmpl3_perms; + data.vmpl2_perms = params.vmpl2_perms; + data.vmpl1_perms = params.vmpl1_perms; + ret = __sev_issue_cmd(argp->sev_fd, SEV_CMD_SNP_LAUNCH_UPDATE, &data, error); + if (ret) { + snp_page_reclaim(inpages[i], e.pagesize); + goto e_unpin; + } + + next_vaddr = (vaddr & pmask) + psize; + } + +e_unpin: + /* Content of memory is updated, mark pages dirty */ + memset(&e, 0, sizeof(e)); + for (i = 0; i < npages; i++) { + set_page_dirty_lock(inpages[i]); + mark_page_accessed(inpages[i]); + + /* + * If its an error, then update RMP entry to change page ownership + * to the hypervisor. + */ + if (ret) + rmpupdate(inpages[i], &e); + } + + /* Unlock the user pages */ + sev_unpin_memory(kvm, inpages, npages); + + return ret; +} + int svm_mem_enc_op(struct kvm *kvm, void __user *argp) { struct kvm_sev_cmd sev_cmd; @@ -1716,6 +1855,9 @@ int svm_mem_enc_op(struct kvm *kvm, void __user *argp) case KVM_SEV_SNP_LAUNCH_START: r = snp_launch_start(kvm, &sev_cmd); break; + case KVM_SEV_SNP_LAUNCH_UPDATE: + r = snp_launch_update(kvm, &sev_cmd); + break; default: r = -EINVAL; goto out; diff --git a/include/linux/sev.h b/include/linux/sev.h index bcd4d75d87c8..82e804a2ee0d 100644 --- a/include/linux/sev.h +++ b/include/linux/sev.h @@ -36,8 +36,10 @@ struct __packed rmpentry { /* RMP page size */ #define RMP_PG_SIZE_4K 0 +#define RMP_PG_SIZE_2M 1 #define RMP_TO_X86_PG_LEVEL(level) (((level) == RMP_PG_SIZE_4K) ? PG_LEVEL_4K : PG_LEVEL_2M) +#define X86_TO_RMP_PG_LEVEL(level) (((level) == PG_LEVEL_4K) ? RMP_PG_SIZE_4K : RMP_PG_SIZE_2M) struct rmpupdate { u64 gpa; diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index dbd05179d8fa..c9b453fb31d4 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1681,6 +1681,7 @@ enum sev_cmd_id { /* SNP specific commands */ KVM_SEV_SNP_INIT = 256, KVM_SEV_SNP_LAUNCH_START, + KVM_SEV_SNP_LAUNCH_UPDATE, KVM_SEV_NR_MAX, }; @@ -1790,6 +1791,23 @@ struct kvm_sev_snp_launch_start { __u8 gosvw[16]; }; +#define KVM_SEV_SNP_PAGE_TYPE_NORMAL 0x1 +#define KVM_SEV_SNP_PAGE_TYPE_VMSA 0x2 +#define KVM_SEV_SNP_PAGE_TYPE_ZERO 0x3 +#define KVM_SEV_SNP_PAGE_TYPE_UNMEASURED 0x4 +#define KVM_SEV_SNP_PAGE_TYPE_SECRETS 0x5 +#define KVM_SEV_SNP_PAGE_TYPE_CPUID 0x6 + +struct kvm_sev_snp_launch_update { + __u64 uaddr; + __u32 len; + __u8 imi_page; + __u8 page_type; + __u8 vmpl3_perms; + __u8 vmpl2_perms; + __u8 vmpl1_perms; +}; + #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0) #define KVM_DEV_ASSIGN_PCI_2_3 (1 << 1) #define KVM_DEV_ASSIGN_MASK_INTX (1 << 2)
The KVM_SEV_SNP_LAUNCH_UPDATE command can be used to insert data into the guest's memory. The data is encrypted with the cryptographic context created with the KVM_SEV_SNP_LAUNCH_START. In addition to the inserting data, it can insert a two special pages into the guests memory: the secrets page and the CPUID page. For more information see the SEV-SNP specification. Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> --- .../virt/kvm/amd-memory-encryption.rst | 28 ++++ arch/x86/kvm/svm/sev.c | 142 ++++++++++++++++++ include/linux/sev.h | 2 + include/uapi/linux/kvm.h | 18 +++ 4 files changed, 190 insertions(+)