linux-kernel - Re: [PATCH v5 12/21] tpm: move pcr extend code to tpm2-cmd.c

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:   Fri, 5 Oct 2018 14:31:47 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     "Winkler, Tomas" <tomas.winkler@...el.com>
Cc:     Jason Gunthorpe <jgg@...pe.ca>,
        Nayna Jain <nayna@...ux.vnet.ibm.com>,
        "Usyskin, Alexander" <alexander.usyskin@...el.com>,
        "Struk, Tadeusz" <tadeusz.struk@...el.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "roberto.sassu@...wei.com" <roberto.sassu@...wei.com>
Subject: Re: [PATCH v5 12/21] tpm: move pcr extend code to tpm2-cmd.c

On Thu, Oct 04, 2018 at 11:45:30AM +0000, Winkler, Tomas wrote:
> There is no API change, in that sense.
> The exported API is in tpm-interface.c int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, const u8 *hash)  
> that is used is outside of the tpm reminds the same, only the open coded implementation of tpm2_pcr_extned has moved to
> tpm2-cmd.c, This code is not called out of tpm module.
> Please review the code again.

I did now revisit this and you are right that my choice of word was not
exactly correct. I apologize for that. The patch introduces API that we
would take away and that does make much sense.

The best way to sort things out is to just fix the warnings and leave
the TPM 2.0 part open coded inside tpm_pcr_extend(). The rationale for
this is to avoid unnecessary mainline changes when ever possible (which
is bad for backporting for stable kernels).

> Thanks
> Tomas

/Jarkko