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