Date: Fri, 26 Sep 2003 13:23:29 -0400 From: Jeroen C.van Gelderen <jeroen@vangelderen.org> To: Nate Lawson <nate@root.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/etc/defaults devfs.rules Message-ID: <25426A04-F046-11D7-9CBF-00039375644C@vangelderen.org> In-Reply-To: <20030926100145.D64861@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. Cheers, -J
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25426A04-F046-11D7-9CBF-00039375644C>