From owner-cvs-src@FreeBSD.ORG Fri Sep 26 16:12:42 2003 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 8954416A4B3; Fri, 26 Sep 2003 16:12:42 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D65043FBD; Fri, 26 Sep 2003 16:12:40 -0700 (PDT) (envelope-from kolmeronline@comcast.net) Received: from 204.127.197.116 ([204.127.197.116]) by comcast.net (rwcrmhc12) with SMTP id <2003092623124001400qi91ne>; Fri, 26 Sep 2003 23:12:40 +0000 Received: from [12.246.2.55] by 204.127.197.116; Fri, 26 Sep 2003 23:12:39 +0000 From: kolmeronline@comcast.net To: Nate Lawson Date: Fri, 26 Sep 2003 23:12:39 +0000 X-Mailer: AT&T Message Center Version 1 (Sep 12 2003) X-Authenticated-Sender: a29sbWVyb25saW5lQGNvbWNhc3QubmV0 Message-Id: <20030926231240.8D65043FBD@mx1.FreeBSD.org> cc: cvs-src@freebsd.org cc: "Jeroen C.van Gelderen" cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/etc/defaults devfs.rules 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: Fri, 26 Sep 2003 23:12:42 -0000 Don't know how you picked up our email address but we are not SUBSCRIBED members .... have tried thru cvs to be removed with no success - please remove us immediately. Thank you. > 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 > _______________________________________________ > cvs-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-all > To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" >