linux-kernel - Re: [PATCH 1/2] [RFC] time: Fix problem with large timespecs & ktime_get_update

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:	Wed, 1 Aug 2012 08:52:42 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	John Stultz <john.stultz@...aro.org>
cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Prarit Bhargava <prarit@...hat.com>,
	Zhouping Liu <zliu@...hat.com>, CAI Qian <caiqian@...hat.com>
Subject: Re: [PATCH 1/2] [RFC] time: Fix problem with large timespecs &
 ktime_get_update_offsets

On Tue, 31 Jul 2012, John Stultz wrote:
> There's currently a slight difference in ktime_get_update_offsets()
> vs ktime_get() which can result in boot time crashes when booting
> with insane CMOS clock values larger then ~2264.
> 
> ktime_get() does basically the following:
>         return timespec_to_ktime(timespec_add(xtime, wall_to_monotonic))
> 
> Where as ktime_get_update_offsets does approximately:
>         return ktime_sub(timespec_to_ktime(xtime), realtime_offset);
> 
> The problem is, at boot we set xtime = year 8200 and
> wall_to_monotonic = year -8200,  ktime_get adds both values, mostly
> nulling the difference out (leaving only how long the system has been
> up), then converts that relatively small value to a ktime_t properly
> without losing any information.
> 
> ktime_get_update_offsets however, since it converts xtime (again set
> to some value greater then year 8200), to a ktime, it gets clamped at
> KTIME_MAX, then we subtract realtime_offset, which is _also_ clamped
> at KTIME_MAX, resulting in us always returning almost[1] zero. This
> causes us to stop expiring timers.
> 
> Now, one of the reasons Thomas and I changed the logic was that using
> the precalculated realtime_offset was slightly more efficient then
> re-adding xtime and wall_to_monotonic's components separately. But
> how valuable this unmeasured slight efficiency is vs extra
> robustness for crazy time values is questionable.
> 
> So switch back to the ktime_get implementation for
> ktime_get_update_offsets

NAK.

You're papering over the real problem: Using crap values without
sanity checking them in the first place.

All your patch does is papering over the problem. Heck, year 8200 is
obvious bullshit, so we can detect and reject it.

Thanks,

	tglx

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