cvs commit: src/etc/defaults devfs.rules

[Nate Lawson]

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