linux-kernel - Re: [PATCH] RTC: Restore alarm after resume

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: <1420498225.18006.6.camel@nebula.com>
Date:	Mon, 5 Jan 2015 22:50:26 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"a.zummo@...ertech.it" <a.zummo@...ertech.it>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>
Subject: Re: [PATCH] RTC: Restore alarm after resume

On Mon, 2015-01-05 at 14:41 -0800, Andrew Morton wrote:
> On Mon, 22 Dec 2014 19:19:39 +0000 Matthew Garrett <matthew.garrett@...ula.com> wrote:
> 
> > Some platform firmware may interfere with the RTC alarm over suspend,
> > resulting in the kernel and hardware having different ideas about system state
> > but also potentially causing problems with firmware that assumes the OS will
> > clean this case up. This patch saves the RTC alarm state on suspend and will
> > restore it on resume if the alarm has not yet fired - if it has, it will clear
> > the RTC alarm.
> 
> There's not really enough info here for me to decide which kernel
> version(s) need the patch.  Can we please expand on "some"?  Any
> suggestions regarding the importance/timing of the fix?

The case we've seen is Intel Rapid Start, which is a firmware-mediated
feature that automatically transitions systems from suspend-to-RAM to
suspend-to-disk without OS involvement. It does this by setting the RTC
alarm and a flag that indicates that on wake it should perform the
transition rather than re-starting the OS. However, if the OS has set a
wakeup alarm that would wake the machine earlier, it refuses to
overwrite it and allows the system to wake instead.

This fails in the following situation:

1) User configures Intel Rapid Start to transition after (say) 15
minutes
2) User suspends to RAM. Firmware sets the wakeup alarm for 15 minutes
in the future
3) User resumes after 5 minutes. Firmware does not reset the alarm, and
as such it is still set for 10 minutes in the future
4) User suspends after 5 minutes. Firmware notices that the alarm is set
for 5 minutes in the future, which is less than the 15 minute transition
threshold. It therefore assumes that the user wants the machine to wake
in 5 minutes
5) System resumes after 5 minutes

The worst case scenario here is that the user may have put the system in
a bag between (4) and (5), resulting in it running in a confined space
and potentially overheating. This seems reasonably important. The Rapid
Start support code got added in 3.11, but it can be configured in the
firmware regardless of kernel support.

I'd like to hear some feedback from the RTC maintainers regarding
whether this is the preferred fix. Doing it in the Rapid Start driver
doesn't seem correct, since as mentioned the feature doesn't require any
kernel support - the kernel code just provides a means for runtime
configuration.