Re: Verifying Execution Integrity in Untrusted hypervisors

Shiva V
2014-07-31T18:25:53Z

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?