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  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 <>
To:     Denis Kenzior <>,
        Mimi Zohar <>,
        Jarkko Sakkinen <>,
        Joe Perches <>
Cc:,,, Mimi Zohar <>,
        David Howells <>,
        James Morris <>,
        Marcel Holtmann <>,
        James Morris <>
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

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.


Powered by blists - more mailing lists