linux-kernel - Re: REGRESSION WITH BISECT: v6.5-rc6 TPM patch breaks S3 on some Intel systems

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, 17 Aug 2023 20:58:42 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Jarkko Sakkinen <jarkko@...nel.org>, todd.e.brandt@...ux.intel.com,
        linux-integrity@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, len.brown@...el.com,
        charles.d.prestopine@...el.com, rafael.j.wysocki@...el.com
Subject: Re: REGRESSION WITH BISECT: v6.5-rc6 TPM patch breaks S3 on some
 Intel systems



On 8/17/2023 5:33 PM, Jarkko Sakkinen wrote:
> On Fri Aug 18, 2023 at 1:25 AM EEST, Todd Brandt wrote:
>> On Fri, 2023-08-18 at 00:47 +0300, Jarkko Sakkinen wrote:
>>> On Fri Aug 18, 2023 at 12:09 AM EEST, Todd Brandt wrote:
>>>> While testing S3 on 6.5.0-rc6 we've found that 5 systems are seeing
>>>> a
>>>> crash and reboot situation when S3 suspend is initiated. To
>>>> reproduce
>>>> it, this call is all that's required "sudo sleepgraph -m mem
>>>> -rtcwake
>>>> 15".
>>>
>>> 1. Are there logs available?
>>> 2. Is this the test case: https://pypi.org/project/sleepgraph/ (never
>>> used it before).
>>
>> There are no dmesg logs because the S3 crash wipes them out. Sleepgraph
>> isn't actually necessary to activate it, just an S3 suspend "echo mem >
>> /sys/power/state".
>>
>> So far it appears to only have affected test systems, not production
>> hardware, and none of them have TPM chips, so I'm beginning to wonder
>> if this patch just inadvertently activated a bug somewhere else in the
>> kernel that happens to affect test hardware.
>>
>> I'll continue to debug it, this isn't an emergency as so far I haven't
>> seen it in production hardware.
> 
> OK, I'll still see if I could reproduce it just in case.
> 
> BR, Jarkko

I'd like to better understand what kind of TPM initialization path has 
run.  Does the machine have some sort of TPM that failed to fully 
initialize perhaps?

If you can't share a full bootup dmesg, can you at least share

# dmesg | grep -i tpm

I think it would be really good to try the following:

0) Start with a machine without this patch in place
1) At bootup run this command:
# tpm2_getcap properties-fixed
2) Suspend machine
3) Repeat that command after suspend
4) Reboot with that patch and repeat steps 1 and 2.