From owner-cvs-all@FreeBSD.ORG Fri Sep 26 11:40:00 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 2384416A4B3 for ; Fri, 26 Sep 2003 11:40:00 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 396BB44025 for ; Fri, 26 Sep 2003 11:39:56 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 65511 invoked by uid 1000); 26 Sep 2003 18:39:57 -0000 Date: Fri, 26 Sep 2003 11:39:57 -0700 (PDT) From: Nate Lawson To: "Jeroen C.van Gelderen" In-Reply-To: <25426A04-F046-11D7-9CBF-00039375644C@vangelderen.org> Message-ID: <20030926112233.X65171@root.org> References: <25426A04-F046-11D7-9CBF-00039375644C@vangelderen.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org 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 18:40:00 -0000 On Fri, 26 Sep 2003, Jeroen C.van Gelderen wrote: > 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. I didn't mean that TSC was required, only that it makes things very convenient. I work for the author of that paper so I'm familiar with how many samples are needed for a given timer resolution. > 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. Many crypto accelerators were designed with the model of being used by multiple non-malicious processes (i.e. SSL servers). Providing separation to multiple malicious processes is a different threat model. > 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. Yes, however most users expect jail to provide a higher level of assurance of user separation than different processes on the same box. My basic point is that this change may make any hardware weaknesses that we don't address more fatal by giving hostile users access to the hardware. I don't object to the change but just wanted to question whether we've written our drivers and evaluated our hardware with this threat model in mind. -Nate