Date: Sun, 22 May 2005 16:46:07 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Colin Percival <cperciva@FreeBSD.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>, Stephan Uphoff <ups@tree.com> Subject: Re: Scheduler fixes for hyperthreading Message-ID: <20050522163024.Q1381@epsplex.bde.org> In-Reply-To: <428FFBB8.5010201@freebsd.org> References: <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm> <428FFBB8.5010201@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 21 May 2005, Colin Percival wrote: > Stephan Uphoff wrote: >> Would it be enough to disable access to RDTSC for user processes? Doing so would be a kernel bug. > On single-core systems (single socket, not dual-core), yes. Otherwise, no. > >> I believe the attack needs a very exact time source. > > It needs ~100 cycle resolution. If you have two processors, you can get > good enough precision for the attack by constructing a "virtual TSC" by > using a second thread which repeatedly increments a location in memory. clock_gettime() with takes about 600 cycles if kern.timecounter.hardware=TSC. It should take fewer cycles, but syscalls are inefficient in FreeBSD. Does a factor of 6 make much difference to the attack? >> Beside benchmarking - is there any other real use for RDTSC ? > > Some (broken) software uses the TSC in combination with external events in > order to obtain entropy for cryptographic key generation. As a result, > disabling RDTSC could lead to non-obvious but very problematic breakage. Profiling (a form of benchmarking) should optionally be high resolution and high resolution profiling would use the TSC if it is available. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050522163024.Q1381>