On 03/09/2016 09:57 PM, Andy Lutomirski wrote:
On Wed, Mar 9, 2016 at 6:34 PM, Stefan Berger
<stef...@linux.vnet.ibm.com> wrote:
On 03/09/2016 01:01 PM, Andy Lutomirski wrote:
On Wed, Mar 9, 2016 at 9:39 AM, Stefan Berger
<stef...@linux.vnet.ibm.com> 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.
Nifty!
Is anyone considering writing a modification or replacement of
trousers that creates claims the real tpm and exposes a vtpm that
handles multiplexing internally? Does the vtpm driver intelligently
support multiple simultaneous clients?
The vtpm driver allows to use an independent trousers instance in each
container.
Using the VTPM_NEW_DEV ioctl the container mgmt. stack can create a
/dev/tpmX (X=0,1,2,...) device and a file descriptor. The file descriptor is
passed to a vTPM instance, the /dev/tpmX is moved into the container,
meaning a device with the same major/minor numbers is created in the
container. This then allows each container to talk to an independent vTPM.
The vTPM can either be 1.2 or 2.
What I meant was:
If two clients connect to the same vTPM slave node, can the master
program tell requests from the two clients apart? If so, great! If
not, then I'd consider that to be somewhat sad.
vTPM slave node being /dev/tpmX? TPM types of devices can currently only
be opened by one application. This can for example be TSS/trousers,
which then offers an API to applications for sending TPM commands. That
only one application is allowed is a limitation of the existing driver.
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
