On 08/29/2018 12:08 PM, Stephen John Smoogen wrote:
On Wed, 29 Aug 2018 at 11:58, Dag Nygren <dag@newtech.fi mailto:dag@newtech.fi> wrote:
On onsdag 29 augusti 2018 kl. 17:39:18 EEST Stephen John Smoogen wrote: > On Wed, 29 Aug 2018 at 10:25, Dag Nygren <dag@newtech.fi <mailto:dag@newtech.fi>> wrote: > > Anyone here with an experience in transitioning QEMU -> XEN ? > http://www.cse.psu.edu/~pdm12/cse544/slides/cse544-schiffman-vTPM.pdf <http://www.cse.psu.edu/%7Epdm12/cse544/slides/cse544-schiffman-vTPM.pdf> goes > through some of the problems. Yes, I had a look at that earlier and it seems XEN has solved most of the problemsWell it seemed that the people writing the talk had come up with a way it could be done. That can be it being done in a way that isn't 3/4 bailing wire and duct tape or it could be that the have a viable set of tools which can be done cleanly and meet various security uses which require knowing what the hostility of the environment is. AKA it may work if you expect no hostile VMs ever to be installed or it may mean it works in a hostile environment where VM A and VM B are owned by different actors and they are actively spying on each other. Each of those has different requirements and outcomes. AKA in one you can expect that secrets in the vTPM may remain secret while the other they may not. And there may be the case where Dom0 could see any secret in any vTPM so you have to factor in how much you trust that.
This brings up an interesting issue.
AWS and others have a problem in that they have security issues because they run VM's for anybody who is willing to pay. This is not true of internal virtualized servers where the hosting and deployment environment are controlled.
I have a client that has about 20 VMs for various purposes and we have determined that installing the meltdown security patches would cause a decrease in performance for a security increase that is very close to 0.
So in this case do the VM's need to be protected from each other or are they all inside a safe controlled network.
> You need to be aware of the limitations of > the specific TPM your hardware has, and what you are giving up in the trust > model with any vTPM [aka your virtual machine can't move from its server, > your TPM isn't real and can possibly looked at by other guests, etc etc.] Couldn't find anything on the issue of migration of the VM, but I thought that Xen has that one also taken care of? (Exporting and importing keys) Am I completely wrong here?I don't really know. From the articles.. it is not a 'simple' operation and you can quite easily get it wrong. Depending on the security arrangements needed further research than a PDF on the Internet is needed with actual questions to the writers or talking with a company that does this full time.
This comes back to the reason for using TPM.
Is this to secure one VM from another or is it being used for something like software licensing validation?
One has serious security implications the other is just making it possible for someone to run a stupid licensing model on a virtual machine.