Functionally if the scheduler doesn't know what it's passing to the CPU or into paging memory a lot of optimization possibilities go out the window. If it does know one can infer a great deal about your datasets protected or not.
-Matt On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara <jus...@fathomdb.com> wrote: > I think that Intel's trusted cloud work is trying to solve that exact > compute host problem. It may already have the framework to do so even if > the software hasn't caught up (i.e. if we still have some work to do!) > > It relies on a TPM chip, all code is measured before being run, and then > there's a protocol to prove that a system is running that code (remote > attestation). If you change the software stack by introducing a sniffer, > you change the hash. So we'd need a stack with no root-access / back-doors. > Once a back-door becomes known, the hash should no longer be trusted. > > I'm by no means an expert (I'm still learning about it), but I believe it is > possible, having read this > paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf > > I'm sure there are still exploits (hardware RAM taps?), and we rely on a > total code audit, but we can raise the bar a long way. > > Anyone from Intel / familiar with Intel's trusted cloud work want to explain > better than I can? > > Justin > > > > > On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce <m...@nycresistor.com> wrote: >> >> As far as storage is concerned, certainly a cloud storage environment >> could be leveraged to store pre-encrypted data in such a way that >> would make it difficult bordering on impossible to seize or access >> without the consent of the owner. >> >> As far as compute hosts are concerned, it is a whole different matter. >> >> For the foreseeable future ( barring the invention of new widely >> distributed in CPU technology ) . Anyone with ring 0 execution access >> on a system ( ie root / sudo ) will be able to pull data from a >> running instance pretty much no matter what you do. >> >> You can certainly raise the bar on difficulty there, but the >> fundamental path of sniffing schedulers / paging memory / etc will be >> there for a fairly long time. Even trusted computing wouldn't be >> applicable to protecting a vm's scheduler from the hypervisors owner. >> >> So, I think functionally it should be assumed that a provider will be >> able to access anything that you access on a hosted VM. As far as a >> trust relationship goes in elastic computing, there must be an >> implicit trust of the cloud provider. And as with any trust >> relationship there is always going to be an element of risk. >> >> -Matt >> >> On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange <berra...@redhat.com> >> wrote: >> > On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: >> >> From a security stand point I am curious what you see the benefit as? >> > >> > Consider that you might have separate people in your data center >> > managing the virtualization hosts, vs the storage hosts vs the >> > network. As it standards today any of those groups of people can >> > compromise data stored in a VM disk image (assuming a network based >> > filesystem). >> > >> > First you encrypt the disk image, so that a person with access >> > to the storage hosts, or network sniffing can't read any data. Then >> > you have a central key server that only gives out the decryption key >> > to Nova compute nodes when they have been explicitly authorized to >> > run an instance of that VM. >> > >> > So now people with access to the storage hosts cannot compromise >> > any data. People with access to the virtualization hosts can only >> > compromise data if the host has been authorized to use that disk >> > image >> > >> > You would need to compromise the precise host the VM disk is being >> > used on, or compromise the key server or the management service >> > that schedules VMs (thus authorizing key usage on a node). >> > >> > NB this is better than relying on the guest OS to do encryption, >> > since you can do stricter decryption key management from the >> > host side. >> > >> >> On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser >> >> <d...@seetheprogress.net> wrote: >> >> > Hey, >> >> > >> >> > I'm following the openstack development for some time now and I was >> >> > wondering if there was a solution to spin up encrypted virtual >> >> > machines by >> >> > default and if it would be a huge performance blow. >> >> > >> >> > Any ideas? >> > >> > I would like to extend the libvirt driver in Nova to make use of the >> > qcow2 >> > encryption capabilities between libvirt & QEMU which I describe here: >> > >> > >> > http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ >> > >> > Regards, >> > Daniel >> > -- >> > |: http://berrange.com -o- >> > http://www.flickr.com/photos/dberrange/ :| >> > |: http://libvirt.org -o- >> > http://virt-manager.org :| >> > |: http://autobuild.org -o- >> > http://search.cpan.org/~danberr/ :| >> > |: http://entangle-photo.org -o- >> > http://live.gnome.org/gtk-vnc :| >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
