linux-kernel - Re: pm: System date and time set incorrectly after suspend/resume to disk

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:	Mon, 17 Jun 2013 19:14:07 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Shuah Khan <shuah.kh@...sung.com>
Cc:	"rjw@...k.pl" <rjw@...k.pl>,
	"a.zummo@...ertech.it" <a.zummo@...ertech.it>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>
Subject: Re: pm: System date and time set incorrectly after suspend/resume to disk

On Mon, Jun 17, 2013 at 6:30 PM, Shuah Khan <shuah.kh@...sung.com> wrote:
> I am seeing a problem on my system after a suspend to disk in reboot or
> shutdown mode. When pm_trace is 0 (which is the default), I can't
> reproduce the problem easily. I have to run a few more suspend tests
> before I see the problem. When pm_trace is disabled, the problem showed
> up when I ran suspend in platform mode in a row. However when pm_ptrace
> is enabled, problem happens on the very first spend to disk in reboot mode.
>
> Steps to run into the issue:
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo reboot > disk
> echo disk > state
>
> or
>
> echo 1 > pm_print_times
> echo 1 > pm_trace
> echo shutdown > disk
> echo disk > state
>
> When system comes back up, system time set to incorrect time.

So I this is by design. Please see Documentation/power/s2ram.txt for details:

"pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
Reason for this is that the RTC is the only reliably available piece of
hardware during resume operations where a value can be set that will
survive a reboot.

Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option."

thanks
-john
--
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/