Scheduler fixes for hyperthreading

Stephan Uphoff ups at tree.com
Sat May 21 19:44:28 PDT 2005


On Sat, 2005-05-21 at 19:11, Colin Percival wrote: 
>   As you are probably all aware by now, HyperThreading has been
> disabled on the stable and security branches due to a problem
> with information leakage between threads which are scheduled
> simultaneously on the two processor cores.  Clearly, some people
> (and at least one large company) are unhappy about us having
> hyperthreading disbaled, so the security team would like to see
> hyperthreading re-enabled by default as soon as we believe that
> this can be done safely.
> 
>   The following must be done before hyperthreading is re-enabled:
> 
> 1. The scheduler must be taught to not run threads on the same
> processor core unless they p_candebug() each other.  For reasons
> of performance and locking, this is probably best accomplished by
> only allowing threads to share a processor core if they belong
> to the same process.
> 2. When a thread is in the kernel, there must be a mechanism for
> it to IPI its siblings and put them to sleep, and then wake them
> up later.  This would be used any time when a thread in the kernel
> is about to handle sensitive data in a non-oblivious manner; IPsec
> is a good example of where this would be necessary.
> 
>   Does anyone want to step forward to work on this?
> 
> Colin Percival

While I have been to your talk I have not read your paper yet and the
following may be totally uninformed (Please be gentle :-) :

Would it be enough to disable access to RDTSC for user processes?
I believe the attack needs a very exact time source.

Beside benchmarking - is there any other real use for RDTSC ?
Is there any use of RDTSC that system requiring the security cannot live
without? (We could even try to emulate the instruction if we really need
to)

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.

Stephan



More information about the freebsd-arch mailing list