Skip site navigation (1)Skip section navigation (2)
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>