Messages in this thread | | | Date | Tue, 6 Jun 2023 23:22:38 +0800 | Subject | Re: [PATCH 3/9] x86/hyperv: Mark Hyper-V vp assist page unencrypted in SEV-SNP enlightened guest | From | Tianyu Lan <> |
| |
On 6/5/2023 8:13 PM, Vitaly Kuznetsov wrote: >> @@ -113,6 +114,11 @@ static int hv_cpu_init(unsigned int cpu) >> >> } >> if (!WARN_ON(!(*hvp))) { >> + if (hv_isolation_type_en_snp()) { >> + WARN_ON_ONCE(set_memory_decrypted((unsigned long)(*hvp), 1)); >> + memset(*hvp, 0, PAGE_SIZE); >> + } > Why do we need to set the page as decrypted here and not when we > allocate the page (a few lines above)?
If Linux root partition boots in the SEV-SNP guest, the page still needs to be decrypted.
> And why do we need to clear it > _after_ we made it decrypted? In case we care about not leaking the > stale content to the hypervisor, we should've cleared it_before_, but > the bigger problem I see is that memset() is problemmatic e.g. for KVM > which uses enlightened VMCS. You put a CPU offline and then back online > and this path will be taken. Clearing VP assist page will likely brake > things. (AFAIU SEV-SNP Hyper-V guests don't expose SVM yet so the > problem is likely theoretical only, but still). >
The page will be made dirt by hardware after decrypting operation and so memset the page after that.
| |