* Verifying Execution Integrity in Untrusted hypervisors @ 2014-07-25 20:11 Shiva V 2014-07-25 20:52 ` Paolo Bonzini 2014-07-28 17:17 ` Joel Schopp 0 siblings, 2 replies; 10+ messages in thread From: Shiva V @ 2014-07-25 20:11 UTC (permalink / raw) To: kvm 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-25 20:11 Verifying Execution Integrity in Untrusted hypervisors Shiva V @ 2014-07-25 20:52 ` Paolo Bonzini [not found] ` <CAAQucXZWvbE0MJyEEeo=6hkwBJi0WkmixcuCzGEXLaZX1+6ziQ@mail.gmail.com> 2014-07-28 17:17 ` Joel Schopp 1 sibling, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2014-07-25 20:52 UTC (permalink / raw) To: Shiva V, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAAQucXZWvbE0MJyEEeo=6hkwBJi0WkmixcuCzGEXLaZX1+6ziQ@mail.gmail.com>]
* Re: Verifying Execution Integrity in Untrusted hypervisors [not found] ` <CAAQucXZWvbE0MJyEEeo=6hkwBJi0WkmixcuCzGEXLaZX1+6ziQ@mail.gmail.com> @ 2014-07-25 22:06 ` Paolo Bonzini 2014-07-26 19:56 ` Andrey Korolyov 0 siblings, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2014-07-25 22:06 UTC (permalink / raw) To: Shivaramakrishnan Vaidyanathan; +Cc: kvm > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-25 22:06 ` Paolo Bonzini @ 2014-07-26 19:56 ` Andrey Korolyov 0 siblings, 0 replies; 10+ messages in thread From: Andrey Korolyov @ 2014-07-26 19:56 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Shivaramakrishnan Vaidyanathan, kvm 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-25 20:11 Verifying Execution Integrity in Untrusted hypervisors Shiva V 2014-07-25 20:52 ` Paolo Bonzini @ 2014-07-28 17:17 ` Joel Schopp 2014-07-28 18:31 ` Jan Kiszka 1 sibling, 1 reply; 10+ messages in thread From: Joel Schopp @ 2014-07-28 17:17 UTC (permalink / raw) To: Shiva V, kvm 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-28 17:17 ` Joel Schopp @ 2014-07-28 18:31 ` Jan Kiszka 2014-07-28 20:27 ` Paolo Bonzini 0 siblings, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2014-07-28 18:31 UTC (permalink / raw) To: Joel Schopp, Shiva V, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-28 18:31 ` Jan Kiszka @ 2014-07-28 20:27 ` Paolo Bonzini 2014-07-28 21:17 ` Nakajima, Jun 0 siblings, 1 reply; 10+ messages in thread From: Paolo Bonzini @ 2014-07-28 20:27 UTC (permalink / raw) To: Jan Kiszka, Joel Schopp, Shiva V, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-28 20:27 ` Paolo Bonzini @ 2014-07-28 21:17 ` Nakajima, Jun 2014-07-29 5:35 ` Jan Kiszka 0 siblings, 1 reply; 10+ messages in thread From: Nakajima, Jun @ 2014-07-28 21:17 UTC (permalink / raw) To: Paolo Bonzini; +Cc: Jan Kiszka, Joel Schopp, Shiva V, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-28 21:17 ` Nakajima, Jun @ 2014-07-29 5:35 ` Jan Kiszka 2014-07-31 18:25 ` Shiva V 0 siblings, 1 reply; 10+ messages in thread From: Jan Kiszka @ 2014-07-29 5:35 UTC (permalink / raw) To: Nakajima, Jun, Paolo Bonzini; +Cc: Joel Schopp, Shiva V, kvm 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Verifying Execution Integrity in Untrusted hypervisors 2014-07-29 5:35 ` Jan Kiszka @ 2014-07-31 18:25 ` Shiva V 0 siblings, 0 replies; 10+ messages in thread From: Shiva V @ 2014-07-31 18:25 UTC (permalink / raw) To: kvm 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? ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-07-31 18:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-25 20:11 Verifying Execution Integrity in Untrusted hypervisors Shiva V 2014-07-25 20:52 ` Paolo Bonzini [not found] ` <CAAQucXZWvbE0MJyEEeo=6hkwBJi0WkmixcuCzGEXLaZX1+6ziQ@mail.gmail.com> 2014-07-25 22:06 ` Paolo Bonzini 2014-07-26 19:56 ` Andrey Korolyov 2014-07-28 17:17 ` Joel Schopp 2014-07-28 18:31 ` Jan Kiszka 2014-07-28 20:27 ` Paolo Bonzini 2014-07-28 21:17 ` Nakajima, Jun 2014-07-29 5:35 ` Jan Kiszka 2014-07-31 18:25 ` Shiva V
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.