linux-kernel - Re: [PATCH] TPM: Let the tpm char device be openable multiple times

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: <20121012205658.GM4124@obsidianresearch.com>
Date:	Fri, 12 Oct 2012 14:56:58 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Kent Yoder <key@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, tpmdd-devel@...ts.sourceforge.net
Subject: Re: [PATCH] TPM: Let the tpm char device be openable multiple times

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/