linux-kernel - Re: [patch] x86: unify/rewrite SMP TSC sync code

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:	Fri, 24 Nov 2006 21:25:14 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <ak@...e.de>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch] x86: unify/rewrite SMP TSC sync code

* Andi Kleen <ak@...e.de> wrote:

> > make the TSC synchronization code more robust, and unify it between 
> > x86_64 and i386.
> > 
> > The biggest change is the removal of the 'fix up TSCs' code on 
> > x86_64 and i386, in some rare cases it was /causing/ time-warps on 
> > SMP systems.
> 
> On x86-64 I don't think it can since it doesn't check anymore on sync 
> Intel.

yeah - the main new bit for x86-64 is the unconditional check for time 
warps. We shouldnt (and cannot) really trust the CPU and the board/BIOS 
getting it right. There were always some motherboards using Intel CPUs 
that had the TSCs wrong.

> > The new code only checks for TSC asynchronity - and if it can prove 
> > a time-warp (if it can observe the TSC going backwards when going 
> > from one CPU to another within a critical section), then the TSC 
> > clock-source is turned off.
> 
> The trouble is that people are using the RDTSC anyways even if the 
> kernel doesn't. So some synchronization is probably a good idea.

which apps are using it? It might be safer in terms of app compatibility 
if we removed the TSC bit in the case where we know it doesnt work, and 
if we turned the feature off in the CPU in this case. We could also try 
to 'approximately' sync up the TSC, but that obviously cannot be used 
for kernel timekeeping - and by offering an 'almost' good TSC to 
userspace we'd lure them towards using something we /cannot/ fix.

nor can the TSC really be synced up properly in the hotplug CPU case, 
after the fact - what if the app already read out an older TSC value and 
a new CPU is added. If the TSC isnt sync on SMP then it quickly gets 
pretty messy, and we should rather take a look at /why/ these apps are 
using RDTSC.

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