Date: Mon, 23 May 2005 09:38:22 +0930 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Colin Percival <cperciva@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading Message-ID: <20050523000822.GF34798@wantadilla.lemis.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
--TeJTyD9hb8KJN2Jy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --TeJTyD9hb8KJN2Jy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCkR72IubykFB6QiMRAhRkAKCMrePxsT7lkVGCurIOxZyZ6TT/eQCfWWnS pKOqKukC4aEgOpG2QAlXjJ4= =6UGp -----END PGP SIGNATURE----- --TeJTyD9hb8KJN2Jy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050523000822.GF34798>