Scheduler fixes for hyperthreading

Bruce Evans bde at zeta.org.au
Sat May 21 23:46:11 PDT 2005


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


More information about the freebsd-arch mailing list