3 ms·
Just an idea that I had: If these exploits seem rely on taking precise timing measurements (on the order of nanoseconds), could we eliminate or restrict this f
by Unklejoe 9y ago
Just an idea that I had:
If these exploits seem rely on taking precise timing measurements (on the order of nanoseconds), could we eliminate or restrict this functionality in user space?
The Spectre exploit uses the RDTSC instruction, and this can apparently be restricted to privilege level 0 by setting the TSD flag in CR4.
I know it would kind of suck, but it might be better than nothing.
I would think that most typical user applications wouldn't require that accurate of a time measurement. If they do, then maybe they can be white listed?
- greenleafjacob 9y agoThat is the approach Firefox is taking [1]: > Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. [1]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan...
- voidmain 9y agoDenying access to timers is kind of practical for browser JavaScript, and should and will happen. But it's not practical for native processes, because shared memory multithreading provides as high precision a timer as anyone could ask for: just increment a counter in a loop in a different thread. In fact, the practical JavaScript attacks use this method (using SharedArrayBuffer) and the browsers are disabling this (new, little used) feature as a mitigation. But I'm afraid hell will freeze over before mainstream operating systems deny userspace access to clocks, threads, and memory mapped files, which is a lower bound on what it would take to make the attack much harder.