Verifying Execution Integrity in Untrusted hypervisors

Verifying Execution Integrity in Untrusted hypervisors

[Shiva V]

Hello,
I am exploring on finding a way to ensure runtime integrity of 

a executable in untrusted hypervisors.

In particular, this is my requirements:

1. I have a 2 virtual machines. (A, B). 

2. VM-A is running some service (exe) inside it. For example any resource 

accounting service intended to monitor for VM-B.

3. I need a way to verify run time integrity from VM-B of the executable 

running inside VM-A.

4. Both the vm's are not privileged vm's and are just normal client virtual 

machines.

5. Underlying hypervisor is untrusted.


Can anyone please shed any direction to proceed.I am stuck here.

Anytime I try to make a progress, I get back to the loop where 

vcpu and the address translations from the guest virtual pages to host

physical pages is handled by the hypervisor and this can be altered.

Re: Verifying Execution Integrity in Untrusted hypervisors

[Paolo Bonzini]

Il 25/07/2014 22:11, Shiva V ha scritto:
> 5. Underlying hypervisor is untrusted.
> 
> Can anyone please shed any direction to proceed.I am stuck here.
> Anytime I try to make a progress, I get back to the loop where 
> vcpu and the address translations from the guest virtual pages to host
> physical pages is handled by the hypervisor and this can be altered.

If the hypervisor is untrusted, the game is over.

You could not do this on an untrusted processor, the hypervisor is the
same thing.

Paolo

Re: Verifying Execution Integrity in Untrusted hypervisors

[Paolo Bonzini]

> Thanks a lot Paolo.
> 
> Is there a way to atleast detect that the hypervisor has done something
> malicious and the client will be able to refer to some kind of logs to
> prove it?

If you want a theoretical, perfect solution, no.  I wouldn't be surprised
if this is equivalent to the halting problem.

If you want a practical solution, you have to define a threat model.  What
kind of attacks are you worried about?  Which parts of the environment can
you control?  Can you place something trusted between the vulnerable VM
and its clients?  And so on.

Paolo

Re: Verifying Execution Integrity in Untrusted hypervisors

[Andrey Korolyov]

On Sat, Jul 26, 2014 at 2:06 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> Thanks a lot Paolo.
>>
>> Is there a way to atleast detect that the hypervisor has done something
>> malicious and the client will be able to refer to some kind of logs to
>> prove it?
>
> If you want a theoretical, perfect solution, no.  I wouldn't be surprised
> if this is equivalent to the halting problem.
>
> If you want a practical solution, you have to define a threat model.  What
> kind of attacks are you worried about?  Which parts of the environment can
> you control?  Can you place something trusted between the vulnerable VM
> and its clients?  And so on.
>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Here are some bits I read before:
https://www.cs.purdue.edu/homes/bb/cs590/papers/secure_vm.pdf. It`s
all about timing measurement after all, if you`ll be able to measure
them or derive methods from, say, cache correlation attacks to avoid
possibility of continuous hijack due to knowledge of amount of
computation/timings which will not be possible with constant Eve
measurements. you can complete task at a half. Complete execution
without continuous checking against locally placed trusted blackbox
equivalent (hardware token, trusted execution replaying or so) is
hardly possible by my understanding. Anyway, any of imaginable cases
relies on a finite amount of computing power available to a single
thread, so I can hardly say that real-world implementation *is
secure*, though we can define high probability of it. I believe that
the homomorphic encryption can do its way for at least some kind of
services by next decade, due to tendency of total cloudization, and
this is definitely better than sticks-and-mud approach with timings.

Re: Verifying Execution Integrity in Untrusted hypervisors

[Joel Schopp]

On 07/25/2014 03:11 PM, Shiva V wrote:
> Hello,
> I am exploring on finding a way to ensure runtime integrity of 
>
> a executable in untrusted hypervisors.
>
> In particular, this is my requirements:
>
> 1. I have a 2 virtual machines. (A, B). 
>
> 2. VM-A is running some service (exe) inside it. For example any resource 
>
> accounting service intended to monitor for VM-B.
>
> 3. I need a way to verify run time integrity from VM-B of the executable 
>
> running inside VM-A.
>
> 4. Both the vm's are not privileged vm's and are just normal client virtual 
>
> machines.
>
> 5. Underlying hypervisor is untrusted.
If the hypervisor is untrusted you have broken the root of trust and are
going to be pretty out of luck.

Any solution will require a level below the hypervisor  that you trust. 
An example would be hardware that isolates memory from the hypervisor,
ie
https://www.google.com/patents/WO2013054528A1?cl=en&dq=Joel+Schopp&hl=en&sa=X&ei=YYPWU6aVJNProATe5IHACQ&ved=0CDMQ6AEwAw

Another approach might be to start with something like a TPM and a
trusted runtime UEFI.  You could then have the guest call UEFI to do
measurement with the TPM and use that for remote attestation.  With such
a method you could probably get to the point that you could measure
something in guest memory at run-time, but you would have no assurance
it hadn't been modified prior or after and was just temporarily correct,
it would be a very point in time measurement.

Re: Verifying Execution Integrity in Untrusted hypervisors

[Jan Kiszka]

On 2014-07-28 19:17, Joel Schopp wrote:
> 
> On 07/25/2014 03:11 PM, Shiva V wrote:
>> Hello,
>> I am exploring on finding a way to ensure runtime integrity of 
>>
>> a executable in untrusted hypervisors.
>>
>> In particular, this is my requirements:
>>
>> 1. I have a 2 virtual machines. (A, B). 
>>
>> 2. VM-A is running some service (exe) inside it. For example any resource 
>>
>> accounting service intended to monitor for VM-B.
>>
>> 3. I need a way to verify run time integrity from VM-B of the executable 
>>
>> running inside VM-A.
>>
>> 4. Both the vm's are not privileged vm's and are just normal client virtual 
>>
>> machines.
>>
>> 5. Underlying hypervisor is untrusted.
> If the hypervisor is untrusted you have broken the root of trust and are
> going to be pretty out of luck.
> 
> Any solution will require a level below the hypervisor  that you trust. 
> An example would be hardware that isolates memory from the hypervisor,
> ie
> https://www.google.com/patents/WO2013054528A1?cl=en&dq=Joel+Schopp&hl=en&sa=X&ei=YYPWU6aVJNProATe5IHACQ&ved=0CDMQ6AEwAw

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...

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: Verifying Execution Integrity in Untrusted hypervisors

[Paolo Bonzini]

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.

Paolo

Re: Verifying Execution Integrity in Untrusted hypervisors

[Nakajima, Jun]

On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini <pbonzini@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.
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.

-- 
Jun
Intel Open Source Technology Center

Re: Verifying Execution Integrity in Untrusted hypervisors

[Jan Kiszka]

On 2014-07-28 23:17, Nakajima, Jun wrote:
> On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini <pbonzini@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

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: Verifying Execution Integrity in Untrusted hypervisors

[Shiva V]

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?