From owner-cvs-src@FreeBSD.ORG Sun May 15 20:14:00 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 60E4916A4CE; Sun, 15 May 2005 20:14:00 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1014743DD5; Sun, 15 May 2005 20:14:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.250] (adsl-64-171-184-162.dsl.snfc21.pacbell.net [64.171.184.162]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j4FKDwLS028582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 May 2005 13:13:58 -0700 Message-ID: <4287AD84.6070600@root.org> Date: Sun, 15 May 2005 13:13:56 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <97079.1116154766@critter.freebsd.dk> In-Reply-To: <97079.1116154766@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Jacques Vidrine cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: Colin Percival Subject: Re: cvs commit: src/sys/amd64/amd64 mp_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: Sun, 15 May 2005 20:14:00 -0000 Poul-Henning Kamp wrote: > In message <4286E6A5.4030902@freebsd.org>, Colin Percival writes: > >>Nate Lawson wrote: >> >>>That is at best, hyperbole. >> >>Have you been talking to Intel lately? >> >> >>> Crypto implementations which properly >>>implement blinding or operate in constant time are not vulnerable. >> >>Crypto implementations which implement blinding are vulnerable. > > > This is not just about crypto. > > There are many processes which a random process should not be allowed > to spy on in a multiuser system. > > Your boss text-procssing or email program for one thing. Every general-purpose machine has measurable timing side channels. The question is merely one of bandwidth. I can time your boss's keystrokes using a loop on an SMP system that runs "ps -l" looking for "ttywait" and get a rough measurement. With enough samples, I can regenerate what he typed. This attack against SSH-encrypted sessions has been shown to be effective. My point was that FreeBSD (like most general-purpose OS) has many timing channels that are comparably as effective for an attacker as HTT. 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? As Colin wrote in his paper, identifying, analyzing, and characterizing the bandwidth of all possible side channels in a system is a very difficult task. There is no way to know whether or not disabling a given feature reduces the probability of a successful attack without doing this analysis. On the other hand, the loss of functionality is quite certain. Given that FreeBSD is a general-purpose OS, we need to limit timing channels the best we can while maintaining the widest possible feature support. Since we can't completely eliminate timing channels, the best hope is for applications that handle secrets to do so in a data-independent way. None of this is easy. -- Nate