linux-kernel - [PATCH 0/2][RFC] Better handling of insane CMOS values

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]

Message-Id: <1343716548-38742-1-git-send-email-john.stultz@linaro.org>
Date:	Tue, 31 Jul 2012 02:35:46 -0400
From:	John Stultz <john.stultz@...aro.org>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	John Stultz <john.stultz@...aro.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Prarit Bhargava <prarit@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Zhouping Liu <zliu@...hat.com>, CAI Qian <caiqian@...hat.com>
Subject: [PATCH 0/2][RFC] Better handling of insane CMOS values

So CAI Qian noticed recent boot trouble on a machine that had its CMOS
clock configured for the year 8200. 
See: http://lkml.org/lkml/2012/7/29/188

While running with a crazy CMOS clock isn't advised, and a simple
"don't do that" might be reasonable, the behavior has in effect
regressed recently due to changes in the hrtimer/timekeeping
interactions.

This patchset tries to resolve this issue in two ways:
1) Change ktime_get_update_offsets to match ktime_get and avoid
possible precision loss with extremely large timespecs.

2) Catch any stop attempt to set the time to a value (circa the
year 2264) large enough to overflow ktime_t.

The end fix here might be an either/or/both combination of these
two changes, so I wanted to send them out for comment. I'm also
looking at further ways to test and improve robustness around
these more extreme time values.

I've also only been able to lightly test. If you want to try this out
you can add the following to timekeeping_init after the
read_persistent_clock() call:

	now.tv_sec = 196469280000LL;

thanks
-john

Cc: Ingo Molnar <mingo@...nel.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Prarit Bhargava <prarit@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Zhouping Liu <zliu@...hat.com>
Cc: CAI Qian <caiqian@...hat.com>

John Stultz (2):
  [RFC] time: Fix problem with large timespecs &
    ktime_get_update_offsets
  [RFC] time: Limit time values that would overflow ktime_t

 kernel/time/timekeeping.c |   40 ++++++++++++++++++++++++++++++----------
 1 file changed, 30 insertions(+), 10 deletions(-)

-- 
1.7.9.5

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