linux-kernel - Re: [Xen-devel] [patch 14/33] xen: xen time implementation

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]

Date:	Wed, 06 Jun 2007 11:30:28 +0200
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Keir Fraser" <keir@...source.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	<virtualization@...ts.osdl.org>,
	"Xen-devel" <xen-devel@...ts.xensource.com>,
	"Chris Wright" <chrisw@...s-sol.org>, "Andi Kleen" <ak@...e.de>,
	"lkml" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [patch 14/33] xen: xen time implementation

>>> Keir Fraser <keir@...source.com> 06.06.07 10:54 >>>
>On 6/6/07 09:39, "Jan Beulich" <jbeulich@...ell.com> wrote:
>
>> The issue is
>> that on that system, transition into ACPI mode takes over 600ms (SMM
>> execution, and hence no interrupts delivered during that time), and with
>> Xen using the PIT (PM timer support was added by Keir as a result of this,
>> but that doesn't cure the problem here, it just reduces the likelihood it'll
>> be encountered) platform time and local time got pretty much out of sync.
>
>If you have an ACPI PM timer in your system (and if you have SMM then your
>system is almost certainly modern enough to have one) then surely the
>problem is fixed for all practical purposes? The problem was overflow of a
>fixed-width platform counter. The PIT wraps every ~50ms, but the ACPI PM
>timer will wrap only every ~4s. It would be quite unreasonable for SMM to
>take the CPU away for multiple seconds, even as a one-time boot operation.

No, I don't think the problem's gone with the PM timer - it is just much less
likely. Since you depend on the TSC (which must generally be assumed be
unsyncronized across CPUs) and on the error correction factor (which shows
non-zero values every few seconds), getting the interpolated times on two
CPUs out of sync is still possible, and given the way the time keeping code
works even being off by just a single nanosecond may be fatal.

Jan

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