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]
Message-ID: <56E1AF44.9040807@linux.vnet.ibm.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ