From owner-cvs-src@FreeBSD.ORG Fri Sep 26 16:12:42 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
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 <nate@root.org>
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" <jeroen@vangelderen.org>
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 <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
<mailto:cvs-src-request@freebsd.org?subject=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"
>