Date: Fri, 26 Sep 2003 23:12:39 +0000 From: kolmeronline@comcast.net To: Nate Lawson <nate@root.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/etc/defaults devfs.rules Message-ID: <20030926231240.8D65043FBD@mx1.FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030926231240.8D65043FBD>