Re: Verifying Execution Integrity in Untrusted hypervisors
Jan Kiszka siemens.com> writes: > > On 2014-07-28 23:17, Nakajima, Jun wrote: > > On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
On 2014-07-28 23:17, Nakajima, Jun wrote: > On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
On Sat, Jul 26, 2014 at 2:06 AM, Paolo Bonzini 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 majord...@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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Verifying Execution Integrity in Untrusted hypervisors
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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Verifying Execution Integrity in Untrusted hypervisors
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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
