Re: Restricting rdtsc [was: kernel aslr]

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Apr 04, 2017 at 05:39:35PM +0200, Maxime Villard wrote:
> sorry for the delay
> 
> Le 31/03/2017 ? 19:23, Andreas Gustafsson a ?crit :
> > It's ASLR that's broken, not rdtsc, and I strongly object to
> > restricting the latter just to that people can continue to gain
> > a false sense of security from the former.
> 
> For your information, side-channels are not only limited to aslr. It has
> been demonstrated too that cache latencies can be used to keylog a privileged
> process, and to steal cryptographic keys.

Time is a basic operating system service.  Lack of cheap precision time is
not an _advantage_ of NetBSD; it is a disadvantage.

As others have noted, our general intention has been to _reduce_ the cost
to an applicaiton of obtaining timestamps in general -- by providing a
commpage with a base value, and allowing libc to use the cycle counter
as a no-system-calls-required way to obtain an offset.  Other operating
systems do this and it is a real advantage for many applicaitons.  If we
block userland access to the cycle counters, this is a nonstarter.

Yes, the ability of malicious code to measure the behavior of critical
system components and facilities is a problem, but I tend to believe the
solution has to be in the implementation of those components and facilities,
not in removing the ability of non-malicious code to make precision
measurements.

We may not have applications in base that use use rdtsc to get quick
timestamps, but they're sure out there.  OpenSSL's MD code used to
use it -- has that changed? -- and I've seen it in database applications,
language runtimes, and numerous other places.  I really don't think it
would be a good idea to cause it to not work in the general case.

Thor