From owner-cvs-all@FreeBSD.ORG Sun Nov 11 19:38:42 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA7016A421; Sun, 11 Nov 2007 19:38:42 +0000 (UTC) (envelope-from flata@magnesium.net) Received: from toxic.magnesium.net (toxic.magnesium.net [207.154.84.15]) by mx1.freebsd.org (Postfix) with ESMTP id 5E13213C4A7; Sun, 11 Nov 2007 19:38:41 +0000 (UTC) (envelope-from flata@magnesium.net) Received: by toxic.magnesium.net (Postfix, from userid 1212) id A89B1DA827; Sun, 11 Nov 2007 11:39:07 -0800 (PST) Date: Sun, 11 Nov 2007 09:39:07 -1000 From: Juli Mallett To: Nate Lawson Message-ID: <20071111193907.GA24725@toxic.magnesium.net> References: <200711081945.lA8JjKcW080540@repoman.freebsd.org> <47337724.9040108@FreeBSD.org> <47337940.6040909@root.org> <47340B74.9070004@freebsd.org> <4734B13C.6050008@root.org> <4735008D.7030600@FreeBSD.org> <473667FF.2010005@freebsd.org> <47374870.1080706@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47374870.1080706@root.org> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Maxim Sobolev , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, Kris Kennaway , cvs-all@FreeBSD.org, Colin Percival Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2007 19:38:42 -0000 * Nate Lawson [ 2007-11-11 ] [ Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c ] > Colin Percival wrote: > > Maxim Sobolev wrote: > >> By the way, I wonder how sun4v (aka Niagara) fares in this respect. As > >> long as I know, they use similar concept, when 8 physical cores can run > >> 32 threads. Should we disable it by default there as well? ;-) > > > > I haven't seen any experiments done on sun4v, but I'm less concerned about > > it since I believe sun4v boxes are used more often for large computing jobs > > rather than for interactive logins with many untrusted users. Of course, > > if/when we have scheduler support for keeping different users on separate > > cores, this should be applied to sun4v as well. > > I don't think locking threads to cores by uid solves the general > problem. Consider a web server, where processes run as the same uid but > represent different customers. What we need is for the software > components that deal with secrets (keys, passwords, etc.) to be able to > specify "don't switch me out until I'm done" for a short quantum. > Restricting access to that mechanism would also be needed to prevent > DoS, same as realtime scheduling. If you really want to do that sort of thing, I don't think you want to trust userland code with it. You could put the sensitive parts of crypto routines in the kernel and run them in a critical section, but I'm not sure it's worth it. We could also let a process request that if we do context switch it out, we cover its tracks a little, assuming we can come up with a mechanism to do that (whether there's a direct one or whether we have to have some code that does some nonsense to overwrite whatever caches.) You could even give such a process a shorter quantum to account for the extra time that would need spent immediately after context switching out from it. If it's doable, that seems far better to any specialization of the code or requiring any sort of extra credentials. Doesn't solve the HTT case, though. If we were to just move the compromisable functionality to the kernel, it would be easy for it to require that any cores which share its branch prediction table, caches, etc., not have anything running at the time it goes into its critical section.