Scheduler fixes for hyperthreading

[Greg 'groggy' Lehey]

On Saturday, 21 May 2005 at 16:11:07 -0700, 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.

Yes, I've read the rest of the thread, but I think we probably need to
step back here and see what we're addressing: this is a security issue
that won't worry the vast majority of users.  It seems that we should
provide a choice:

* For the really paranoid, disable HTT altogether.
* For the relatively paranoid, something like what you propose above.
* For the moderate risk-takesrs and the pedantic, provide a system
  call that tells the scheduler when the process is going through a
  critical section that could be vulnerable to this kind of attack,
  and that until further notice no other process (or only one what
  meets that meets the criteria above) should be scheduled.  This
  would require a "further notice" system call as well, of course.
* For those who have no serious security concerns (trusted
  environments, probably the majority of users), simply enable HTT.

Greg
--
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20050523/0dad4e2d/attachment.bin