linux-kernel - System automatically wakes up because of Intel Rapid Start Technology

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-next>] [day] [month] [year] [list]

Date:	Mon, 22 Dec 2014 14:59:38 +0100
From:	Gabriele Mazzotta <gabriele.mzt@...il.com>
To:	platform-driver-x86@...r.kernel.org
Cc:	mjg59@...f.ucam.org, linux-kernel@...r.kernel.org
Subject: System automatically wakes up because of Intel Rapid Start Technology

Hi,

I'd like to ask those of you who own a system that supports Intel Rapid 
Start Technology (IRST) to perform a simple test to determine whether my 
laptop (XPS13 9333) is the only system affected by a bug related to IRST 
that I recently found or not.

In the past months I noticed random transitions from S3 to S0 with no 
apparent reason.
After some recent tests I found a way to trigger those automatic state 
transitions. It seems that the timer in charge of the resume of the 
system for the transition to S4 is not re-initialized on resume/suspend. 
Exactly "wakeup_time" minutes after the transition from S0 to S3, the 
system will automatically transition from S3 to S0 instead of S4 if
within that interval it transitioned to S0 at least once.
Everything works as expected if the system is never resumed or if the 
system is suspended after "wakeup_time" minutes have passed since the
first suspension to ram.

In addition to that, changing the values of wakeup_time and 
wakeup_events seems to have no effect until the timer has expired.

According to the Implementation Guide [1] there are no special 
requirements other than the standard S3 ACPI support. Still, IRST works 
as intended only on Windows. This makes me wonder whether the problem is 
due to some vendor specific change or not.

To quickly replicate the problem, follow the following steps: set the 
timer to 1 minute and suspend the system. Immediately after that, resume 
and suspend the system again. If it automatically wakes up after 1 
minute has passed since the first suspension, then the system is
affected by the bug. If this is the case, I'd suggest to default
wakeup_events to 0 or 2 to prevent issues and add some sort of warning
somewhere to let users know about this problem.

Regards,
Gabriele

[1] http://downloadmirror.intel.com/22647/eng/Intel%20Rapid%20Start%20Technology%20Deployment%20Guide%20v1.0.pdf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/