Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-19 Thread Jarkko Sakkinen
On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> This patch implements a proxy driver for supporting multiple emulated TPMs
> in a system.
> 
> The driver implements a device /dev/vtpmx that is used to created
> a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that
> is accessed using a file descriptor returned by an ioctl.
> The device /dev/tpmX is the usual TPM device created by the core TPM
> driver. Applications or kernel subsystems can send TPM commands to it
> and the corresponding server-side file descriptor receives these
> commands and delivers them to an emulated TPM.
> 
> Signed-off-by: Stefan Berger 
> CC: linux-ker...@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> CC: linux-...@vger.kernel.org

Alternative to this would be to have /dev/vtpmx create:

* /dev/vtpm0 for the server
* /dev/tpm0 for the client

This is how David Howell's PoC worked and that's why I want
to make this alternative visible.

The server could even respawn without container noticing it.
This solution have better availability properties.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-19 Thread Jason Gunthorpe
On Wed, Mar 16, 2016 at 02:09:16PM +0200, Jarkko Sakkinen wrote:
> On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:

> Alternative to this would be to have /dev/vtpmx create:
> 
> * /dev/vtpm0 for the server
> * /dev/tpm0 for the client
> 
> This is how David Howell's PoC worked and that's why I want
> to make this alternative visible.
> 
> The server could even respawn without container noticing it.
> This solution have better availability properties.

Seriously, no, that doesn't make any sense. TPM is stateful, you can't
respawn the server side.

If anyone is ever clever enough to make that workable then they just
go ahead and save the server fd with the other state. systemd for
instance already has everything needed to make that work.

We don't need to have a server dev node and we certainly don't need
the leaking problem that leaves us with.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-19 Thread Stefan Berger

On 03/16/2016 04:42 PM, Jarkko Sakkinen wrote:

On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:

+
+/* above flags */
+#define VTPM_PROXY_FLAG_TPM2  1  /* emulator is TPM 2 */
+
+/* all supported flags */
+#define VTPM_PROXY_FLAGS_ALL  (VTPM_PROXY_FLAG_TPM2)

This can be moved inside the .c-file?


I can move that.




+
+#define VTPM_PROXY_MAGIC 0xa1
+
+#define VTPM_PROXY_IOC_NEW_DEV   _IOW(VTPM_PROXY_MAGIC, 0x00, \
+ struct vtpm_proxy_new_dev)

Could we simply replace these four lines with one line:

#deifne VTPM_PROXY_IOC_NEW_DEV _IOW('t', 0x00, struct vtpm_proxy_new_dev);


Does this make it better?



I changed the magic but does it matter?


I would keep the magic at '0xa1'. The documentation is written to '0xa1' 
now and seems to be good just as any other.


   Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-19 Thread Stefan Berger

On 03/16/2016 08:09 AM, Jarkko Sakkinen wrote:

On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:

This patch implements a proxy driver for supporting multiple emulated TPMs
in a system.

The driver implements a device /dev/vtpmx that is used to created
a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that
is accessed using a file descriptor returned by an ioctl.
The device /dev/tpmX is the usual TPM device created by the core TPM
driver. Applications or kernel subsystems can send TPM commands to it
and the corresponding server-side file descriptor receives these
commands and delivers them to an emulated TPM.

Signed-off-by: Stefan Berger 
CC: linux-ker...@vger.kernel.org
CC: linux-doc@vger.kernel.org
CC: linux-...@vger.kernel.org

Alternative to this would be to have /dev/vtpmx create:

* /dev/vtpm0 for the server
* /dev/tpm0 for the client

This is how David Howell's PoC worked and that's why I want
to make this alternative visible.


My initial implementation had this as well.



The server could even respawn without container noticing it.
This solution have better availability properties.


A TPM should be stable enough to not have to be respawned...

Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-19 Thread Jarkko Sakkinen
On Wed, Mar 16, 2016 at 11:49:04AM -0600, Jason Gunthorpe wrote:
> On Wed, Mar 16, 2016 at 02:09:16PM +0200, Jarkko Sakkinen wrote:
> > On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> 
> > Alternative to this would be to have /dev/vtpmx create:
> > 
> > * /dev/vtpm0 for the server
> > * /dev/tpm0 for the client
> > 
> > This is how David Howell's PoC worked and that's why I want
> > to make this alternative visible.
> > 
> > The server could even respawn without container noticing it.
> > This solution have better availability properties.
> 
> Seriously, no, that doesn't make any sense. TPM is stateful, you can't
> respawn the server side.
> 
> If anyone is ever clever enough to make that workable then they just
> go ahead and save the server fd with the other state. systemd for
> instance already has everything needed to make that work.
> 
> We don't need to have a server dev node and we certainly don't need
> the leaking problem that leaves us with.

Fair enough.

> Jason

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-18 Thread Jarkko Sakkinen
On Fri, Mar 18, 2016 at 10:52:00AM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 17, 2016 at 01:45:20PM -0400, Stefan Berger wrote:
> > On 03/16/2016 04:42 PM, Jarkko Sakkinen wrote:
> > >On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> > >>+
> > >>+/* above flags */
> > >>+#define VTPM_PROXY_FLAG_TPM2  1  /* emulator is TPM 2 */
> > >>+
> > >>+/* all supported flags */
> > >>+#define VTPM_PROXY_FLAGS_ALL  (VTPM_PROXY_FLAG_TPM2)
> > >This can be moved inside the .c-file?
> > 
> > I can move that.
> > 
> > >
> > >>+
> > >>+#define VTPM_PROXY_MAGIC 0xa1
> > >>+
> > >>+#define VTPM_PROXY_IOC_NEW_DEV   _IOW(VTPM_PROXY_MAGIC, 0x00, \
> > >>+   struct vtpm_proxy_new_dev)
> > >Could we simply replace these four lines with one line:
> > >
> > >#deifne VTPM_PROXY_IOC_NEW_DEV _IOW('t', 0x00, struct vtpm_proxy_new_dev);
> > 
> > Does this make it better?
> > 
> > >
> > >I changed the magic but does it matter?
> > 
> > I would keep the magic at '0xa1'. The documentation is written to '0xa1' now
> > and seems to be good just as any other.
> 
> OK. Works for me. Keep the ioctl definition as it is.
> 
> Reviewed-by: Jarkko Sakkinen 
> 
> I can move the constant. You don't have to send a new patch version
> anymore. I start keeping this patch in my master but will not merge it
> to next before 4.6-rc5 so at the moment it would be scheduled for 4.7.
> Does this sound good for you?
> 
> Further improvemnts should be sent as separate fixup patches.

Applied to git://git.infradead.org/users/jjs/linux-tpmdd.git.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v8 08/10] tpm: Proxy driver for supporting multiple emulated TPMs

2016-03-14 Thread Jarkko Sakkinen
On Sun, Mar 13, 2016 at 06:54:38PM -0400, Stefan Berger wrote:
> This patch implements a proxy driver for supporting multiple emulated TPMs
> in a system.
> 
> The driver implements a device /dev/vtpmx that is used to created
> a client device pair /dev/tpmX (e.g., /dev/tpm10) and a server side that
> is accessed using a file descriptor returned by an ioctl.
> The device /dev/tpmX is the usual TPM device created by the core TPM
> driver. Applications or kernel subsystems can send TPM commands to it
> and the corresponding server-side file descriptor receives these
> commands and delivers them to an emulated TPM.

Tested-by: Jarkko Sakkinen 

My testing procedure was:

* Wine running TPM 2.0 simulator on the host side. [1]
* QEMU running an OS image with this patch. [2]
* Wrote a script for proxying the simulator: tpm2-simulator-vtpm. [3]
* Run some smoke tests: python -m unittest -v tpm2_smoke. [3]

[1] 
http://research.microsoft.com/en-us/downloads/35116857-e544-4003-8e7b-584182dc6833/
[2] git://git.infradead.org/users/jjs/buildroot-tpmdd.git
[3] git://git.infradead.org/users/jjs/tpm2-scripts.git

/Jarkko

> Signed-off-by: Stefan Berger 
> CC: linux-ker...@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> CC: linux-...@vger.kernel.org
> ---
>  drivers/char/tpm/Kconfig  |  10 +
>  drivers/char/tpm/Makefile |   1 +
>  drivers/char/tpm/tpm_vtpm_proxy.c | 572 
> ++
>  include/uapi/linux/Kbuild |   1 +
>  include/uapi/linux/vtpm_proxy.h   |  42 +++
>  5 files changed, 626 insertions(+)
>  create mode 100644 drivers/char/tpm/tpm_vtpm_proxy.c
>  create mode 100644 include/uapi/linux/vtpm_proxy.h

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html