linux-kernel - Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

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:   Thu, 05 Jan 2017 10:06:35 -0800
From:   James Bottomley <jejb@...ux.vnet.ibm.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        "Fuchs, Andreas" <andreas.fuchs@....fraunhofer.de>
Cc:     "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "tpmdd-devel@...ts.sourceforge.net" 
        <tpmdd-devel@...ts.sourceforge.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Thu, 2017-01-05 at 10:27 -0700, Jason Gunthorpe wrote:
> On Thu, Jan 05, 2017 at 03:52:02PM +0000, Fuchs, Andreas wrote:
> > Great to see this coming along so well. Thanks a lot to Jarkko !
> 
> > The TPM allows an application to get the list of currently loaded
> > handles TPM2_GetCapabilities(TPM_CAP_HANDLES).  It would be great 
> > to have the RM be as transparent to userspace as possible. The RM 
> > spec of TCG therefore says that you need to intercept and override
> > this
> 
> I'd rather just ban unnecessary stuff like this on the RM fd.
> Tracking active handles can be done in userspace by the app
> itself. Debugging can be done by using the non-RM fd or debugfs.

Yes, we basically agreed on not doing this.  The only handles that
actually need translating are the transient 0x80 ones.  Since the RM
effectively segregates them, you can't see anyone else's, so the only
query could be about the application's own transient handles and it's
difficult to see how it could lose track of them and want to issue this
query.  So the best course is to leave it unimplemented (less code) and
see if anyone complains because they have an actual use case.

James