cvs commit: src/etc/defaults devfs.rules

[kolmeronline at comcast.net]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/cvs-all
> To unsubscribe, send any mail to "cvs-all-unsubscribe at freebsd.org"
>