The timing based attacks depend on the granularity of timestamps. I feel
what's available here is too coarse grained to be useful. Happy to
disable the code at compile time for those cases. Are there
CONFIG_HIGH_SECURITY type of options I could use for this purpose?
It allows anyone to detect with very high precision when context
switches happen on another CPU. This sounds a little dangerous. I
don't know if a config option is the right choice.
Yes - this should be a separate patch. gcc-4.4 likes to get rid of the
instruction in __do_thread_cpu_time without the asm volatile (in spite of
the memory clobber).
gcc 4.4 caught a genuine bug in your code. You ignored the return
value (which is an output constraint), so you weren't using any
outputs and gcc omitted the apparently useless code. The right fix is
to check the return value. (And to consider adding the missing
volatile.)
+ if (vp->tsc_unstable) {
+ struct timespec ts;
+ vdso_fallback_gettime(CLOCK_THREAD_CPUTIME_ID,&ts);
+ return timespec_to_ns(&ts);
+ }
Yuck -- another flag indicating whether we're using the tsc.
I renamed it to thread_cputime_disabled to deal with NR_CPUS> 64.
Still yuck. IMO this should always work.
Sorry, I was unclear. gtod_data contains vclock_mode, which will tell
you whether the tsc is usable. I have a buggy computer (I'm typing
this email on it) that has a TSC that is only useful per-process. I
don't think it's worth supporting this particular case, since it's a
bios bug and needs fixing by the vendor. It's hopefully rare.