> adding random noise just makes attacks take longer
No. It's true that with a low-res clock source in some cases an attacker can still get the precise measurement they're after by repeating an operation 1000x+ more times. In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc.
Anyway, even if a lower-res clock source helps only 10% of the time, on defense you should always prefer to make an attack complicated, slow, partially-reliable rather than trivial, fast, highly-reliable.
Developers who need a high-res clock source for profiling, etc, should of course still be able to enable one selectively.
> You need to address the specific vulnerabilities, not shoot the clock_gettime messenger.
You can and should do both, to gain some defense-in-depth against future attacks.
No. It's true that with a low-res clock source in some cases an attacker can still get the precise measurement they're after by repeating an operation 1000x+ more times. In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc.
Anyway, even if a lower-res clock source helps only 10% of the time, on defense you should always prefer to make an attack complicated, slow, partially-reliable rather than trivial, fast, highly-reliable.
Developers who need a high-res clock source for profiling, etc, should of course still be able to enable one selectively.
> You need to address the specific vulnerabilities, not shoot the clock_gettime messenger.
You can and should do both, to gain some defense-in-depth against future attacks.