public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Shiva V <shivaramakrishnan740@gmail.com>
To: kvm@vger.kernel.org
Subject: Re: Verifying Execution Integrity in Untrusted hypervisors
Date: Thu, 31 Jul 2014 18:25:37 +0000 (UTC)	[thread overview]
Message-ID: <loom.20140731T202052-316@post.gmane.org> (raw)
In-Reply-To: 53D732B7.4030706@siemens.com

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?




      reply	other threads:[~2014-07-31 18:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20140731T202052-316@post.gmane.org \
    --to=shivaramakrishnan740@gmail.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox