Scheduler fixes for hyperthreading

Colin Percival cperciva at freebsd.org
Sat May 21 16:30:35 PDT 2005


  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


More information about the freebsd-arch mailing list