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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <410e3045-58dc-5415-30c1-c86eb916b6c8@sit.fraunhofer.de>
Date:   Fri, 6 Jan 2017 09:43:29 +0100
From:   Andreas Fuchs <andreas.fuchs@....fraunhofer.de>
To:     James Bottomley <jejb@...ux.vnet.ibm.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>
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

Am 05.01.2017 um 19:06 schrieb James Bottomley:
> 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.

Then how about blocking
TPM2_GetCapabilities(TPM_CAP_HANDLES, 0x80000000) ?

My concern is with a consistent view, so you either get the correct
result or no result, but please no false results...