Re: Hyper-Threading Vulnerability

Lee Revell
2005-05-14T19:21:50Z

On Sat, 2005-05-14 at 20:01 +0200, Arjan van de Ven wrote:
> On Sat, 2005-05-14 at 13:56 -0400, Lee Revell wrote:
> > On Sat, 2005-05-14 at 18:44 +0200, Arjan van de Ven wrote:
> > > then JACK is terminally broken if it doesn't have a fallback for non-
> > > rdtsc cpus.
> >
> > It does have a fallback, but the selection is done at compile time. It
> > uses rdtsc for all x86 CPUs except pre-i586 SMP systems.
> >
> > Maybe we should check at runtime,
>
> it's probably a sign that JACK isn't used on SMP systems much, at least
> not on the bigger systems (like IBM's x440's) where the tsc *will*
> differ wildly between cpus...

Correct. The only bug reports we have seen related to the use of the
TSC is due to CPU frequency scaling. The fix is to not use it - people
who want to use their PC as a DSP for audio probably don't want their
processor slowing down anyway. And JACK is targeted at desktop and
smaller systems, it would be kind of crazy to run it on a big iron.
Well, maybe there are people who like to record sessions or practice
guitar in the server room...

If gettimeofday is really as cheap as rdtsc on x86_64, we should use it.
But it's too expensive for slower x86 systems. Anyway, Andi's fix
disables *all* high res timing including gettimeofday. Obviously no
multimedia app can tolerate this, so discussing rdtsc is really a red
herring. But multimedia apps aren't much in seccomp environments
either.

Lee