Re: Scheduler fixes for hyperthreading

From: Anton Bobrov (Anton.Bobrov_at_Sun.COM)
Date: 05/23/05

  • Next message: David O'Brien: "Re: AMD64 NUMA-awareness?" 
    Date: Mon, 23 May 2005 03:54:26 +0200
To: Colin Percival <cperciva@freebsd.org>

    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"
    _______________________________________________
    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"

  • Next message: David O'Brien: "Re: AMD64 NUMA-awareness?"

    Relevant Pages

    • 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: 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
      ... > hyperthreading disbaled, so the security team would like to see ... The scheduler must be taught to not run threads on the same ... > processor core unless they p_candebugeach other. ...
      (freebsd-arch)