linux-kernel - Re: [PATCH v6 08/11] tpm: Driver for supporting multiple emulated TPMs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2016 12:30:44 -0500
From:	Stefan Berger <stefanb@...ux.vnet.ibm.com>
To:	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc:	tpmdd-devel@...ts.sourceforge.net, jgunthorpe@...idianresearch.com,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-api@...r.kernel.org
Subject: Re: [PATCH v6 08/11] tpm: Driver for supporting multiple emulated
 TPMs

 > On Wed, Mar 09, 2016 at 12:39:27PM -0500, Stefan Berger wrote:
 > > This patch implements a 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.
 >
 > I wrote my first test program 'tpm2-simulator-vtpm' that at the moment
 > opens /dev/vtpmx and creates a device. As next step I'm going to
 > extend this script to connect MS TPM 2.0 simulator based on the work
 > by Peter Huewe.
 >
 > It is available here:
 >
 > git://git.infradead.org/users/jjs/tpm2-scripts.git
 >
 > The first obvious thing that I observed is that the device is closed
 > when /dev/vtpmx is closed.

I don't see how closing the /dev/vtpmx file descriptor would influence 
the device pair, if that's what you are referring to with 'device'? I 
tried that with vtpmctrl.c and the device pair stays unaffected. When 
the applications terminates, the device disappears, unless the server 
side file descriptor has been passed to an external program, so that is 
expected behavior.

 >
 > Some might want to use this in a way that the created virtual device
 > is not closed when /dev/vtpmx is closed.

I don't see that happening. If you want the device pair to stay around 
after an application terminates, you have to pass the file descriptor 
returned from the ioctl to an application.

     Stefan