linux-kernel - Re: [PATCH v4 1/2] tpm: Unify the send callback behaviour

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:   Mon, 11 Feb 2019 16:05:39 +0100
From:   Alexander Steffen <Alexander.Steffen@...ineon.com>
To:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Stefan Berger <stefanb@...ux.ibm.com>
CC:     <linux-integrity@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-security-module@...r.kernel.org>,
        Peter Huewe <PeterHuewe@....de>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH v4 1/2] tpm: Unify the send callback behaviour

On 08.02.2019 20:00, Jarkko Sakkinen wrote:
> On Fri, Feb 08, 2019 at 01:12:34PM -0500, Stefan Berger wrote:
>> On 2/8/19 1:08 PM, Jarkko Sakkinen wrote:
>>> The send() callback should never return length as it does not in every
>>> driver except tpm_crb in the success case. The reason is that the main
>>> transmit functionality only cares about whether the transmit was
>>> successful or not and ignores the count completely.
>>>
>>> Cc: stable@...r.kernel.org
>>> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
>>
>> Reviewed-by: Stefan Berger <stefanb@...ux.ibm.com>
>>
>> Let me know when you put it into your tree, I'll give it a spin while I am
>> at it. :-)
> 
> Thank you Stefan! I also add your suggested-by to the first commit
> because you pointed out the problem.
> 
> It all looks now legit, but just in case I'll add a check for the return
> value to tpm_try_transmit() and a warning if it is not zero in the
> success case (and after that zeroing of rc).
> 
> That check can be removed when I do v5.3 pull request. That should
> enough window to catch any potential issues and check will ensure that
> kernel won't fail even there was something forgotten.
> 
> Alexander, I'll push this version now to the master and next with the
> additional check described in this commit, but will add your tags
> after you have time to test.

I ran all tests again and everything works now as expected :)

Tested-by: Alexander Steffen <Alexander.Steffen@...ineon.com>

Alexander