Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 May 2005 03:54:26 +0200
From:      Anton Bobrov <Anton.Bobrov@Sun.COM>
To:        Colin Percival <cperciva@freebsd.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: Scheduler fixes for hyperthreading
Message-ID:  <429137D2.10801@sun.com>
In-Reply-To: <428FC00B.3080909@freebsd.org>
References:  <428FC00B.3080909@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429137D2.10801>