From owner-cvs-src@FreeBSD.ORG Mon May 16 17:18:48 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8606416A4CE; Mon, 16 May 2005 17:18:48 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0498E43D90; Mon, 16 May 2005 17:18:48 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j4GHHqXw017750; Mon, 16 May 2005 13:17:53 -0400 Message-ID: <4288D5EA.9020202@root.org> Date: Mon, 16 May 2005 10:18:34 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Roberson References: <97079.1116154766@critter.freebsd.dk> <4287AD84.6070600@root.org> <20050516080031.GD34537@server.vk2pj.dyndns.org> <20050516053818.E53620@mail.chesapeake.net> In-Reply-To: <20050516053818.E53620@mail.chesapeake.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: src-committers@FreeBSD.org cc: Jacques Vidrine cc: Peter Jeremy cc: cvs-all@FreeBSD.org cc: Poul-Henning Kamp cc: Colin Percival cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64mp_machdep.csrc/sys/amd64/include cpufunc.h src/sys/i386/i386 mp_machdep.c src/sys/i386/include cpufunc.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 17:18:48 -0000 Jeff Roberson wrote: > On Mon, 16 May 2005, Peter Jeremy wrote: >>On Sun, May 15, 2005 at 01:13:56PM -0700, Nate Lawson wrote: >> >>>My point was that FreeBSD (like most general-purpose OS) has many timing >>>channels that are comparably as effective for an attacker as HTT. >> >>If you take the bandwidth of the timing channel into account, I don't >>believe there are any other timing channels that come anywhere near the >>HTT attack. Maybe Colin has a better idea of what other timing channels >>exist and how they compare to HTT. See my previous email. Even with a 1 bit per second channel, a 1024 bit secret would be revealed in 17 minutes. In nearly every common use case, there is no difference from a security standpoint between a compromise taking 1 second or 17 minutes. In light of this threat model, disabling HTT to fix timing attacks is similar to removing strcpy in hopes of eliminating buffer overflows. Sure it may be the most commonly misused function, but the attacker still has memcpy, strcat, sprintf, integer overflows, etc. >>>Disabling HTT does not significantly reduce an attacker's likelihood of >>>success since they can just use another timing channel. However, it >>>does disable a useful feature. Are we going to disable SMP next? >> > Long term for HTT, if intel keeps it implemented the way it is now, I was > intending to only schedule threads from the same process on the second > core. I believe this would leave it as an optimization which will only > effect the few cases that it is likely to help. > > Anyway, I am not going to throw in my .02 on whether or not it should be > disabled, but I will say that both schedulers have some awareness of htt. I think making the scheduler do this is a great solution. -- Nate