Hacker News Reader

Comment by Taniwha | Hacker News Reader

I wonder if an optional microcode update disabling usermode access to cache flush and rdtsc instructions would make it impossible to do the low level timings required to make the measurements

(of course it would break other stuff, but maybe being able to enable these process by process might be appropriate)

View on HN

thinking about it more a patch that masks out (or sets) the N LSBs of the value returned to user space accesses to rdtsc might do the trick, it wouldn't break anything, and time would still be monotonic

The recent CCC paper on how to write your own microcode (for AMD CPUs) means that AMD owners can actually experiment with a fix of this on their own CPUs ... now if only Intel would let us hack the microcode on our own CPUs too ....

Just masking the lower bits is not enough: you can easily reconstruct a high-precision timer from that by observing the clock edges (waiting until rtdsc increases): wait for clock edge, do your experiment, increase counter until next clode edge in busy loop. the counter now correlates strongly with the amount of time taken for the experiment.

Also, while cache flushes are the easiest way to trigger this, I am not convinced that there aren't other ways to do it. For example, you could attempt to clear the cache by spamming it with new data to cache, or you could try to use one of the other sidechannels (I've seen ALU ports being mentioned as one alternative: instead of accessing cache lines, you do some heavy math operations that will cause the ALU ports of the cpu to be used and then you observe how long ALU operations take in userspace)

There is already a mechanism to disable rdtsc in CR4, I don't know that it's used by anything though

I think that the intent of that was for virtualisation (before we had real virtualisation)

Reply on news.ycombinator.com