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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Oct 2012 11:33:24 -0500
From:	Kent Yoder <key@...ux.vnet.ibm.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.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 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()
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.

Kent

> So, remove the kernel restriction that only one process may open the TPM.
> - TPM low level functions (in kernel users) are already locked proprely
>   and can run in parallel with the user space interface anyhow.
> - Move the user space data buffer and related goop into a
>   struct tpm_file, create one struct tpm_file per open file.
> 
> Signed-off-by: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
> ---
>  drivers/char/tpm/tpm.c |   97 +++++++++++++++++++++---------------------------
>  drivers/char/tpm/tpm.h |   23 ++++++-----
>  2 files changed, 55 insertions(+), 65 deletions(-)
> 
> This is rebase, retest, resend of a patch I sent two years ago. The
> discussion on that earlier patch fizzled out. Resending incase there
> is renewed interest :)
> 

--
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/

Powered by blists - more mailing lists