Scheduler fixes for hyperthreading
Anton Bobrov
Anton.Bobrov at Sun.COM
Sun May 22 18:51:51 PDT 2005
or perhaps processor sets + processor bindings + tweakable
config/api system to allow users to do what they like could
address that, no? i know thats alot of work however what you
suggest in point 1 + point 2 aint a piece of cake either so
as long as somebody goes with the complication maybe its a
good idea to make a flexible system that will address other
problems and benefits as well? just a thought...
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
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
More information about the freebsd-arch
mailing list