linux-kernel - Re: [PATCH v4 2/2] rtc-cmos: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160921200928.pq4ub7miunc33hxh@piout.net>
Date:   Wed, 21 Sep 2016 22:09:28 +0200
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Gabriele Mazzotta <gabriele.mzt@...il.com>
Cc:     a.zummo@...ertech.it, rtc-linux@...glegroups.com,
        linux-kernel@...r.kernel.org, matthew.garrett@...ula.com
Subject: Re: [PATCH v4 2/2] rtc-cmos: Restore alarm after resume

On 20/09/2016 at 01:12:44 +0200, Gabriele Mazzotta 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 restores the RTC alarm on resume
> to ensure that kernel and hardware are in sync.
> 
> 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.
> 
> Signed-off-by: Gabriele Mazzotta <gabriele.mzt@...il.com>
> ---
>  drivers/rtc/rtc-cmos.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com