Re: timing attacks
Who needs to fire off events at precise _times_? The usual events are "required data is in memory" or "disk has confirmed that the data will be read back as required even if the power fails right now". Delete the high resolution timer, and the vast majority of software would not even notice.
Back when I was a PFY, the scheduler interrupt was 50Hz - if you hogged the (only!) CPU for 40ms the OS would give something else a turn. Even back then, if the current process stalled, the scheduler would pick a different unstalled process immediately. Later, Intel CPU's got caches huge enough to hold multiple copies of the enormous state required by the X86 architecture, so the tick could be moved to 1000Hz without continuously thrashing the cache. (Linux got tickless for battery life).
Databases need to put requests into an order, and I always assumed they used a sequence number for that rather than the time. Make has difficulty with FAT's 2 second (!) resolution last modified time stamps. I am sure uuid and NTP actually need nanosecond accuracy, but apart for a few oddities the only contexts I have actually seen using nanosecond accuracy are performance monitoring for optimisation and malware cache timing attacks.
Most software does not touch the high resolution timers at all, so I too am interested in why restricting access to them is not a solution.
Biting the hand that feeds IT
