Re: Scheduler fixes for hyperthreading

From: Greg 'groggy' Lehey (grog_at_FreeBSD.org)
Date: 05/23/05

  • Next message: Stephan Uphoff: "Re: Scheduler fixes for hyperthreading" 
    Date: Mon, 23 May 2005 09:38:22 +0930
To: Colin Percival <cperciva@freebsd.org>

    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 message: Stephan Uphoff: "Re: Scheduler fixes for hyperthreading"

    Relevant Pages

    • Re: Scheduler fixes for hyperthreading
      ... > hyperthreading disbaled, so the security team would like to see ... > processor core unless they p_candebugeach other. ... I have to think more about possible scheduler changes. ...
      (freebsd-arch)
    • Re: Scheduler fixes for hyperthreading
      ... config/api system to allow users to do what they like could ... > hyperthreading disbaled, so the security team would like to see ... > processor core unless they p_candebugeach other. ... This would be used any time when a thread in the kernel ...
      (freebsd-arch)
    • Scheduler fixes for hyperthreading
      ... As you are probably all aware by now, HyperThreading has been ... disabled on the stable and security branches due to a problem ... processor core unless they p_candebugeach other. ... This would be used any time when a thread in the kernel ...
      (freebsd-arch)
    • Re: Dual core CPUs, but only 2 CPUs in-use?
      ... Tigger wrote: ... It's the same security issue, but it's handled differently on 5.x since ... See machdep.hyperthreading_allowed sysctl. ... try benchmarking the system with and without hyperthreading (on ...
      (freebsd-questions)
    • Re: On a hyperthreaded system, top and gnome system monitor only report one processor
      ... > Top lists all process as being run by processor 0 ... > linux it shows two). ... Hyperthreading is disabled by default for security reasons. ...
      (freebsd-current)