From owner-cvs-all@FreeBSD.ORG Fri Sep 26 10:23:35 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47F1C16A4B3; Fri, 26 Sep 2003 10:23:35 -0700 (PDT) Received: from possum.cryptohill.net (cambist.cryptohill.net [24.244.145.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D77B43FDF; Fri, 26 Sep 2003 10:23:30 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from vangelderen.org (grolsch.cryptohill.net [24.244.145.13]) by possum.cryptohill.net (Postfix) with ESMTP id 2CBF1AE308; Fri, 26 Sep 2003 13:23:29 -0400 (EDT) Date: Fri, 26 Sep 2003 13:23:29 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Nate Lawson From: Jeroen C.van Gelderen In-Reply-To: <20030926100145.D64861@root.org> Message-Id: <25426A04-F046-11D7-9CBF-00039375644C@vangelderen.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Poul-Henning Kamp cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc/defaults devfs.rules X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 26 Sep 2003 17:23:35 -0000 On Friday, Sep 26, 2003, at 13:03 US/Eastern, Nate Lawson wrote: > On Fri, 26 Sep 2003, Poul-Henning Kamp wrote: >> Modified files: >> etc/defaults devfs.rules >> Log: >> As far as we know, there is no reason to not expose /dev/crypto in >> jails so code in there can take advantage of hardware assisted >> crypto. >> >> Revision Changes Path >> 1.2 +1 -0 src/etc/defaults/devfs.rules > > Except for the fact that you don't want to combine access to the TSC > and > this paper: > > http://citeseer.nj.nec.com/kocher96timing.html You don't need a TSC source to execute a timing attack because you don't need absolute timing deltas. Any user program can approximate the required time deltas by using counters of various sorts; Even loops will do, albeit less efficiently. Therefore timing attacks can only be prevented by the crypto device driver / hardware combination. Iff /dev/crypto allows for timing attacks, /dev/crypto must be fixed. Quality hardware prevents timing attacks but if the hardware itself doesn't prevent them you can straightforwardly implement blinding in the driver. None of this is limited to jails, the threat exists outside jails too. You don't want any program, jailed or not, to be able to extract keys from the hardware. Cheers, -J