public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Kent Yoder <key@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, tpmdd-devel@lists.sourceforge.net
Subject: Re: [PATCH] TPM: Let the tpm char device be openable multiple times
Date: Fri, 12 Oct 2012 14:56:58 -0600	[thread overview]
Message-ID: <20121012205658.GM4124@obsidianresearch.com> (raw)
In-Reply-To: <20121010163324.GB5013@ennui.austin.ibm.com>

On Wed, Oct 10, 2012 at 11:33:24AM -0500, Kent Yoder wrote:
> On Sun, Sep 30, 2012 at 05:33:45PM -0600, Jason Gunthorpe wrote:
> > How to use the TPM is really a user space policy choice, if the
> > environment wants to use middleware then fine, but it is possible to
> > make correct TPM apps without using middleware.
> 
>   I'm not sure how I feel about this. The single open rule doesn't
> prevent replacement of the middleware, it just requires a
> open()/close()

I'm not interested in replacing the middleware, our designs do not use
any middleware and several processes are required to access the TPM at
once.

Using open/close is an interesting idea, but it wouldn't work. open()
is coded to return EBUSY if another process has it open, rather than
block, and spinning on open would be unacceptable.

> around any use of the device node. That seems simple enough to me. In
> places where you do want TSS to be the sole opener, it can't enforce
> that rule itself, so I think we need to preserve the option of a single
> open at a minimum.

I agree, but I'm not sure how to expose this function? I've seen other
places abuse O_EXCL for this, but that would not be compatible with
existing implementations.

Three things come to mind
 - O_EXCL means the open only succeeds if it the only open and
   prevents others (not compatible)
 - Some other O_ flag is hijacked to mean the opposite of the above
   (yuk)
 - A sysfs flag is added to turn on the new O_EXCL behavior

What do you think?

Jason

  reply	other threads:[~2012-10-12 20:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-30 23:33 [PATCH] TPM: Let the tpm char device be openable multiple times Jason Gunthorpe
2012-10-01  9:07 ` [tpmdd-devel] " Peter.Huewe
2012-10-01 16:09   ` Jason Gunthorpe
2012-10-10 16:33 ` Kent Yoder
2012-10-12 20:56   ` Jason Gunthorpe [this message]
2012-10-15  8:35     ` [tpmdd-devel] " Peter.Huewe
2012-10-15 16:39       ` Jason Gunthorpe
2012-10-15 16:49         ` Alan Cox
2012-10-15 16:56           ` Jason Gunthorpe
2012-10-15 22:02     ` Kent Yoder
  -- strict thread matches above, loose matches on Subject: below --
2009-11-03  0:35 Jason Gunthorpe
2009-11-03 10:43 ` Alan Cox
2009-11-03 17:15   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121012205658.GM4124@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=key@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tpmdd-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox