Jan Kiszka <jan.kiszka <at> siemens.com> writes: > > On 2014-07-28 23:17, Nakajima, Jun wrote: > > On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini <pbonzini <at> redhat.com> wrote: > >> Il 28/07/2014 20:31, Jan Kiszka ha scritto: > >>> The hypervisor has full control of and insight into the guest vCPU > >>> state. Only protecting some portions of guest memory seems insufficient. > >>> > >>> We rather need encryption of every data that leaves the CPU or moves > >>> from guest to host mode (and decryption the other way around). I guess > >>> that would have quite some performance impact and is far from being easy > >>> to integrate into modern processors. But, who knows... > >> > >> Intel SGX sounds somewhat like what you describe, but I'm not sure how > >> it's going to be virtualized. > >> > > > > Right. It's possible to virtualize (or pass-through) SGX without > > losing the security feature. > > Interesting thing. Somehow missed this so far. Fairly complicated one, > though. Still trying to wrap my head around how attestation practically > works. > > > With SGX, you can create secure (encrypted) islands on processes in > > VMs as well. But I'm not sure if it's useful for solving the problem > > described. > > Huh? I thought remote attestation is a key feature of SGX? That is, to > my understanding, what Shiva is looking for (though on current hardware, > which remains infeasible unfortunately). > > Jan > I was going through the Write xor Execute memory protection scheme and thought if this could be the solution. I think if we lock down the code pages of the hypervisor and corresponding to the memory pages and then allow the handler to temporary unlock. (Assuming the operation is atomic). But I dont the security threats associated here. Can anyone point me in right direction? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
