All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Nakajima, Jun" <jun.nakajima@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: Joel Schopp <joel.schopp@amd.com>,
	Shiva V <shivaramakrishnan740@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Verifying Execution Integrity in Untrusted hypervisors
Date: Tue, 29 Jul 2014 07:35:51 +0200	[thread overview]
Message-ID: <53D732B7.4030706@siemens.com> (raw)
In-Reply-To: <CAL54oT3rCskbh0Dik3v3Pgvu4GZyve_nGr=+wT+LuvwohOZwOw@mail.gmail.com>

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

  reply	other threads:[~2014-07-29  5:36 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 [this message]
2014-07-31 18:25           ` Shiva V

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=53D732B7.4030706@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=joel.schopp@amd.com \
    --cc=jun.nakajima@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=shivaramakrishnan740@gmail.com \
    /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 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.