linux-kernel - Re: Suspend/Resume issue in 4.8-rc8

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161010120706.GA3853@intel.com>
Date:   Mon, 10 Oct 2016 15:07:06 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Genki Marshall <genki@...ki.is>
Cc:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Peter Huewe <peterhuewe@....de>,
        Marcel Selhorst <tpmdd@...horst.net>,
        tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: Suspend/Resume issue in 4.8-rc8

On Mon, Oct 10, 2016 at 02:36:43AM -0400, Genki Marshall wrote:
>   Hello,
> 
> On 4.8-rc8, I'm having an issue with laptop suspend/resume for the
> Chromebook Pixel (2015). Specifically:
> 
> When on commit 24532f7 on Linus's tree (latest commit at time of
> writing) I'm having the following issue happen consistently:
> 
> 1. Close lid.
> 2. Wait for CPU to wind down and laptop lid's light to go off.
> 3. Open lid.
> 4. Observe that the computer is booting from scratch.
> 
> I noticed that 4.8-rc7 was working fine. Bisecting, I found 0c54133 to
> be the commit at which this issue starts happening, which is a
> patch to drivers/char/tpm/tpm-interface.c .
> 
> I confirmed this is still relevant as I can proceed to checkout
> 24532f7 again, do a git revert 0c54133, recompile, and the issue no
> longer happens.
> 
> It's a very small patch. Looking through the code, it's strange, as it
> seems to use the tpm_pcr_read_dev() helper correctly (to my totally
> untrained eye).
> 
> In the version with 0c54133 _reverted_, when I make the values of 'rc'
> be printed, recompile, and then resume my laptop (which again, it does
> successfully), I see the values go like:
> 
>   rc = tpm_transmit(chip, (u8 *) &cmd, READ_PCR_RESULT_SIZE, 0);
>   /* rc == 30 here */
>   ...
>   rc = be32_to_cpu(cmd.header.out.return_code);
>   /* rc == 0 here */
> 
> So it returns 0 correctly as expected. But tpm_transmit_cmd() looks
> like it should do effectively the same thing (calling tpm_transmit()
> then calling be32_to_cpu()), and it would just be that rc == 0 right
> away. It started to be difficult to debug as I can't see the results
> of prints when resuming on the broken tree (as it goes straight to
> rebooting).
> 
> Anyway, I was advised on #kernel-newbies that at this point it would
> be best to just email in like this. Let me know if it would be helpful
> for me to answer/test anything.

Sure. Thank you for sending this and taking time to provide a detailed
description. I'll come back to this ASAP.

>   Genki

Email is fine. I also try to track bugzilla.kernel.org for TPM related
bugs.

/Jarkko