From owner-freebsd-arch@FreeBSD.ORG Mon May 23 00:08:27 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61E3516A41C; Mon, 23 May 2005 00:08:27 +0000 (GMT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 827C343D54; Mon, 23 May 2005 00:08:24 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 8F45E85642; Mon, 23 May 2005 09:38:22 +0930 (CST) Date: Mon, 23 May 2005 09:38:22 +0930 From: Greg 'groggy' Lehey To: Colin Percival Message-ID: <20050523000822.GF34798@wantadilla.lemis.com> References: <428FC00B.3080909@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TeJTyD9hb8KJN2Jy" Content-Disposition: inline In-Reply-To: <428FC00B.3080909@freebsd.org> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-arch@freebsd.org Subject: Re: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 00:08:27 -0000 --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--