linux-kernel - Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'

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]

Date:   Tue, 26 Mar 2019 09:25:23 -0700
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Denis Kenzior <denkenz@...il.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Joe Perches <joe@...ches.com>
Cc:     linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org,
        keyrings@...r.kernel.org, Mimi Zohar <zohar@...ibm.com>,
        David Howells <dhowells@...hat.com>,
        James Morris <jmorris@...ei.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        James Morris <james.morris@...rosoft.com>
Subject: Re: Bad file pattern in MAINTAINERS section 'KEYS-TRUSTED'

On Tue, 2019-03-26 at 09:59 -0500, Denis Kenzior wrote:
> Hi James,
> 
> On 03/26/2019 09:25 AM, James Bottomley wrote:
> > Looking at the contents of linux/keys/trusted.h, it looks like the
> > wrong decision to move it.  The contents are way too improperly
> > named
> > and duplicative to be in a standard header.  It's mostly actually
> > TPM
> > code including a redefinition of the tpm_buf structure, so it
> > doesn't
> > even seem to be necessary for trusted keys.
> 
> The reason this was done was because asym_tpm.c needed a bunch of
> the same functionality already provided by trusted.c, e.g.
> TSS_authmac and  friends.

So make a header which only includes those.  We can't have things like
this:

struct tpm_buf {
	int len;
	unsigned char data[MAX_BUF_SIZE];
};

Which means you can't include drivers/char/tpm/tpm.h with this file. 
The storeX functions are also way too generically named and are, in
fact, duplicating the tpm buffer functions in tpm.h

The solution looks to be to elevate agreed tpm_buf functions into
linux/tpm.h and use them.

> > If you want to fix this as a bug, I'd move it back again, but long
> > term I think it should simply be combined with trusted.c because
> > nothing else can include it sanely anyway.
> 
> Ideally I'd like to see the TPM subsystem expose these functions
> using some proper API / library abstraction.  David Howells had an
> RFC patch set that tried to address some of this a while back.  Not
> sure if that went anywhere.

I'm not actually sure I saw it but the solution seems pretty simple:
The TSS functions you want can be renamed tpm1_whatever and we can put
them in tpm1-cmd.c ... tpm2-cmd.c is where all the TPM 2.0 trusted key
stuff is anyway.

James