Scheduler fixes for hyperthreading
Colin Percival
cperciva at freebsd.org
Sat May 21 20:25:53 PDT 2005
Stephan Uphoff wrote:
> Would it be enough to disable access to RDTSC for user processes?
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.
> 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.
> I have to think more about possible scheduler changes.
> Currently we don't even know if a thread running on another virtual CPU
> is in the kernel or not.
> Throwing preemption, interrupt and kernel threads, pinned
> threads,priority inheritance and the IPIs in the mix make correct and
> efficient hyperthreading safe scheduling difficult.
> This also looks like a lot of work and I am wondering if it would not be
> better spend on other scheduler improvements.
If nobody wants to do this, then we could always just keep on telling our
users "sorry, hyperthreading is broken on multi-user systems". I don't
mind, personally -- I only have one system with a hyperthreaded cpu, and I
have hyperthreading turned off for performance reasons. :-)
Colin Percival
More information about the freebsd-arch
mailing list