On 17/03/2017 12:33, Borislav Petkov wrote: > On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote: > >> If it is possible to do it in a fairly hypervisor-independent manner, >> I'm all for it. That is, only by looking at AMD-specified CPUID leaves >> and at kernel ELF sections. > > Not even that. > > What that needs to be able to do is: > > kvm_map_percpu_hv_shared(st, sizeof(*st))) > > where st is the percpu steal time ptr: > > struct kvm_steal_time *st = &per_cpu(steal_time, cpu); > > Underneath, what it does basically is it clears the encryption mask from > the pte, see patch 16/32. Yes, and I'd like that to be done with a new data section rather than a special KVM hook. > And I keep talking about SEV-ES because this is going to expand on the > need of having a shared memory region which the hypervisor and the guest > needs to access, thus unencrypted. See > > http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf > > This is where you come in and say what would be the best approach there... I have no idea. SEV-ES seems to be very hard to set up at the beginning of the kernel bootstrap. There's all sorts of chicken and egg problems, as well as complicated handshakes between the firmware and the guest, and the way to do it also depends on the trust and threat models. A much simpler way is to just boot under a trusted hypervisor, do "modprobe sev-es" and save a snapshot of the guest. Then you sign the snapshot and pass it to your cloud provider. Paolo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
