On onsdag 29 augusti 2018 kl. 10:00:39 EEST Sandro Bonazzola wrote:

2018-08-28 13:52 GMT+02:00 Dag Nygren dag@newtech.fi:

...

We have a desperate need for TPM support and:

1. Tried the "standard" distro install. linvirt supports

TPM passthrough but kvm-qemu barfs: "unsupported configuration: The QEMU executable /usr/libexec/qemu-kvm does not support TPM backend type passthrough"

2. The activated the qemu-ev repo and updated qemu-kvm to version 2.10.0,

which for sure should support at least passthrough. No luck - Same error message. Downloaded the source for th rpm and found a line: "--disable-tpm" in build_configure.sh. Guess that the maintainers has some reason to turn tpm off. Can somone confirm this?

Not sure about reasons for turning off, but request to enable it has been closed wontfix: https://bugzilla.redhat.com/show_bug.cgi?id=1327947

Thanks for the comments and reactions so far!

Well. Changed -disable-tpm to enable-tpm in the rpmbuild and built myself a version with TPM passthrough enabled. Just to find out that it only supports tpm_tis in 2.10.0 and our device only seem to speak tpm_cdr :-(. Bugger.. But we really do need multiple VM:s accessing the hardware TPM anyway and this would only give us one VM ...

Also downloaded qemu 2.12.0 and tried to very optimistically just throw it in the rpmbuild. And got a heap of patch fails already at the first patch. Expected of course... So no such luck.

Now looking further it also seems like even 2.12.0 will not solve our problem as it only gives multiple VM access to the swtpm emulator. We need access to the hardware TPM...

Can you make swtpm use the hardware ?

Any advice would/will be valuable!

Best Dag

On onsdag 29 augusti 2018 kl. 15:37:47 EEST Alvin Starr wrote:

On 08/29/2018 07:38 AM, Dag Nygren wrote:

...

On onsdag 29 augusti 2018 kl. 10:00:39 EEST Sandro Bonazzola wrote:

...

2018-08-28 13:52 GMT+02:00 Dag Nygren dag@newtech.fi:

...

We have a desperate need for TPM support and:

1. Tried the "standard" distro install. linvirt supports TPM passthrough but kvm-qemu barfs: "unsupported configuration: The QEMU executable /usr/libexec/qemu-kvm

does not support TPM backend type passthrough"

2. The activated the qemu-ev repo and updated qemu-kvm to version 2.10.0,

which for sure should support at least passthrough. No luck - Same error message. Downloaded the source for th rpm and found a line: "--disable-tpm" in build_configure.sh. Guess that the maintainers has some reason to turn tpm off. Can somone confirm this?

Not sure about reasons for turning off, but request to enable it has been closed wontfix: https://bugzilla.redhat.com/show_bug.cgi?id=1327947

Thanks for the comments and reactions so far!

Well. Changed -disable-tpm to enable-tpm in the rpmbuild and built myself a version with TPM passthrough enabled. Just to find out that it only supports tpm_tis in 2.10.0 and our device only seem to speak tpm_cdr :-(. Bugger.. But we really do need multiple VM:s accessing the hardware TPM anyway and this would only give us one VM ...

Also downloaded qemu 2.12.0 and tried to very optimistically just throw it in the rpmbuild. And got a heap of patch fails already at the first patch. Expected of course... So no such luck.

Now looking further it also seems like even 2.12.0 will not solve our problem as it only gives multiple VM access to the swtpm emulator. We need access to the hardware TPM...

Can you make swtpm use the hardware ?

Any advice would/will be valuable!

You could try using Xen. A quick search implies that Xen from 4.3 onward will virtualize TPM. I am not sure if the libvirt drivers for xen will support the feature but some work around may be possible.

Thanks! Seems to be exactly what is needed.

The problem here is that we have invested a lot of work and money in a QEMU solution already and have everything else working smoothly... The client just recently figured out that they will need TPM so nobody looked for it until now.

But I will look into this!

Best Dag

On onsdag 29 augusti 2018 kl. 15:37:47 EEST Alvin Starr wrote:

You could try using Xen. A quick search implies that Xen from 4.3 onward will virtualize TPM. I am not sure if the libvirt drivers for xen will support the feature but some work around may be possible.

Nice attitude and helpfulness in this list!

Just had a look and it doesn't seem to be that an intrusive change going from QEMU to XEN.

pacemaker,corosync and libvirt all seem to isolate the engine and most settings should work as is.

Anyone here with an experience in transitioning QEMU -> XEN ?

Best Dag

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 wrote:

...

Anyone here with an experience in transitioning QEMU -> XEN ?

http://www.cse.psu.edu/~pdm12/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 problems

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?

Best Dag

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 problems

Well 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.

On 08/30/2018 07:13 AM, Dag Nygren wrote:

On onsdag 29 augusti 2018 kl. 20:19:22 EEST Alvin Starr wrote:

...

So in this case do the VM's need to be protected from each other or are they all inside a safe controlled network.

No, the environment is quite controlled. What need to be achieved is that IF someone steal the image for one or several of the VM:s they will not be able to emulate the functionality on any other hardware platform.

The VM:s are together making up a functional setup where they are all needed. Isolation between them is not critical.

Your other options would be to use something like LUKS to encrypt the images and get the decription keys from a remote key server. That way if the whole computer is stolen the thieves will not be able to start any VM without the key server.

In either case if the thieves manage to get a root account on any of the servers then they will be able to use normal copy tools to extract as much data as they desire.

A more likely scenario would be that after some time the servers get turned off because of newer and shinier servers have been installed. Now somebody from Accounting sells the servers to someone to recover that last little bit of value and nobody thinks to scrub the data.

I know this happens because I once bought a tape system that had ALL of the backups from an HMO in California.

...

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.

No licensing :-)

Best Dag