Date: Sun, 15 May 2005 11:49:29 -0700 From: Peter Wemm <peter@wemm.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c Message-ID: <200505151149.30989.peter@wemm.org> In-Reply-To: <20050513.114610.28861585.imp@bsdimp.com> References: <200505130057.j4D0v4ZB025346@repoman.freebsd.org> <20050513123909.GW837@darkness.comp.waw.pl> <20050513.114610.28861585.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 13 May 2005 10:46 am, M. Warner Losh wrote: > In message: <20050513123909.GW837@darkness.comp.waw.pl> > > Pawel Jakub Dawidek <pjd@freebsd.org> writes: > : On Fri, May 13, 2005 at 12:57:04AM +0000, Jacques Vidrine wrote: > : +> nectar 2005-05-13 00:57:04 UTC > : +> > : +> FreeBSD src repository > : +> > : +> Modified files: > : +> sys/amd64/amd64 mp_machdep.c > : +> sys/i386/i386 mp_machdep.c > : +> Log: > : +> Default hyperthreading on in -CURRENT. No seatbelts in > : CURRENT (^_^) > : > : Are we sure people don't use 6-CURRENT in production for some > : purposes? I don't disagree about keeping HTT enable in -CURRENT, > : but maybe we want at least print a warning on boot or something. > > Yes. If you based a production system off of CURRENT, you are > assumed to know what you are doing. Secondly, this whole attack requires local code-execution access to the machine in question. The vast majority of FreeBSD users who have hyperthreading hardware are going to want it on because there are no untrusted users on their machines. Therefore, we need to make sure that the feature works and continues to work. If we disable it everywhere by default, the chances are greatly improved of it getting bitrot. We've all seen this before. Feature is turned off. Somebody writes something and doesn't test it with the feature enabled, breaking the feature. When committed, the people who run with the feature enabled get burned. Circus follows, but half of the people who had it enabled give up and turn it off. Lather rinse repeat. Before long, the feature is so marginalized that only the most hardcore folks persist with trying to get it working again. Yes, this kind of thing is reversible, and its arguable that this could happen to such an important feature (to many people) like htt. But we've seen must-have features falling victim to this process before, some have recovered, some not. Examples to think about.. PREEMPTION, SCHED_ULE, etc. The bottom line is that we need features to be enabled as much as possible to ensure the widest testing possible, even if they're going to be off by default on releases or whatever. I'd actually like htt to be turned on in RELENG_5 as well, for that matter. (I'll leave the release branches to the re/so folks). I'll wager that most of the linux folks will just patch the most sensitive software and leave HTT turned on by default. They'll kick our butts. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505151149.30989.peter>