linux-kernel - Re: [PATCH] tpm_tis: use default timeout value if chip reports it as zero

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:   Thu, 26 Jan 2017 00:58:57 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     tpmdd-devel@...ts.sourceforge.net,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        Christophe Ricard <christophe.ricard@...il.com>,
        Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: Re: [PATCH] tpm_tis: use default timeout value if chip reports it as
 zero

On Wed, Jan 25, 2017 at 10:26:44PM +0100, Maciej S. Szmigiero wrote:
> On 25.01.2017 21:09, Jarkko Sakkinen wrote:
> > On Tue, Jan 24, 2017 at 02:42:29PM +0100, Maciej S. Szmigiero wrote:
> >> On 24.01.2017 13:01, Jarkko Sakkinen wrote:
> >>> On Mon, Jan 23, 2017 at 06:23:55PM +0100, Maciej S. Szmigiero wrote:
> >>>> On 16.01.2017 17:39, Jarkko Sakkinen wrote:
> >>>>> On Mon, Jan 16, 2017 at 03:58:26PM +0100, Maciej S. Szmigiero wrote:
> >>>>>> On 16.01.2017 14:55, Jarkko Sakkinen wrote:
> >>>>>>> On Mon, Jan 16, 2017 at 03:46:12PM +0200, Jarkko Sakkinen wrote:
> >>>>>>>> On Mon, Jan 16, 2017 at 11:42:02AM +0200, Jarkko Sakkinen wrote:
> >>>>>>>>> On Fri, Jan 13, 2017 at 10:37:00PM +0100, Maciej S. Szmigiero wrote:
> >>>>>>>>>> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM
> >>>>>>>>>> access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no
> >>>>>>>>>> longer works.
> >>>>>>>>>> The initialization proceeds fine until we get and start using chip-reported
> >>>>>>>>>> timeouts - and the chip reports C and D timeouts of zero.
> >>>>>>>>>>
> >>>>>>>>>> It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
> >>>>>>>>>> means to override the chip returned timeouts") we had actually let default
> >>>>>>>>>> timeout values remain in this case, so let's bring back this behavior to
> >>>>>>>>>> make chips like Atmel 3203 work again.
> >>>>>>>>>>
> >>>>>>>>>> Use a common code that was introduced by that commit so a warning is
> >>>>>>>>>> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
> >>>>>>>>>> timeouts aren't chip-original.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Maciej S. Szmigiero <mail@...iej.szmigiero.name>
> >>>>>>>>>>
> >>>>>>>>>> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM access")
> >>>>>>>>>> Cc: stable@...r.kernel.org
> >>>>>>>>>
> >>>>>>>>> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
> >>>>>>>>
> >>>>>>>> It's now applied to my master branch so if someone wants to
> >>>>>>>> test it, it should be fairly easy.
> >>>>>>>
> >>>>>>> And I decided to squash the rename commit to it.
> >>>>>>
> >>>>>> Wouldn't it be better to squash the rename commit into "fix iTPM probe via
> >>>>>> probe_itpm() function" patch (if it isn't too late), since they touch the
> >>>>>> same functionality?
> >>>>>
> >>>>> It can be renamed, modified and even dropped as long as it is in my
> >>>>> master branch and I haven't sent pull request to James Morris.
> >>>>
> >>>> I see that "fix iTPM probe via probe_itpm() function" patch isn't present
> >>>> in your pull request for 4.11.
> >>>>
> >>>> What I meant in previous message was that you squashed and "rename
> >>>> TPM_TIS_ITPM_POSSIBLE to TPM_TIS_ITPM_WORKAROUND" patch into "use default timeout
> >>>> value if chip reports it as zero" patch while it was logically connected with
> >>>> "fix iTPM probe via probe_itpm() function" patch instead (which now isn't present
> >>>> at all in the tree).
> >>>> Sorry if it wasn't 100% clear.
> >>>
> >>> I see.
> >>>
> >>> I'll probably send later on pull request with fixes for release content
> >>> I can include that commit into that pull request. Does that work for
> >>> you?
> >>
> >> Yes, it would be fine, thanks.
> > 
> > It's now applied and pushed.
> 
> Almost there: it looks like the last hunk of the patch is missing from
> the commit.
> 
> > /Jarkko
> 
> Maciej

Sorrya about that (too much multitasking lately). I had to do a bit of
manual work to get it there. Now it should be good.

/Jarkko