Scheduler fixes for hyperthreading

[Colin Percival]

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