Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 May 2005 20:25:44 -0700
From:      Colin Percival <cperciva@freebsd.org>
To:        Stephan Uphoff <ups@tree.com>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Scheduler fixes for hyperthreading
Message-ID:  <428FFBB8.5010201@freebsd.org>
In-Reply-To: <1116729865.1917.92.camel@palm>
References:  <428FC00B.3080909@freebsd.org> <1116729865.1917.92.camel@palm>

next in thread | previous in thread | raw e-mail | index | archive | help
Stephan Uphoff wrote:
> Would it be enough to disable access to RDTSC for user processes?

On single-core systems (single socket, not dual-core), yes.  Otherwise, no.

> I believe the attack needs a very exact time source.

It needs ~100 cycle resolution.  If you have two processors, you can get
good enough precision for the attack by constructing a "virtual TSC" by
using a second thread which repeatedly increments a location in memory.

> Beside benchmarking - is there any other real use for RDTSC ?

Some (broken) software uses the TSC in combination with external events in
order to obtain entropy for cryptographic key generation.  As a result,
disabling RDTSC could lead to non-obvious but very problematic breakage.

> I have to think more about possible scheduler changes.
> Currently we don't even  know if a thread running on another virtual CPU
> is in the kernel or not.
> Throwing preemption, interrupt and kernel threads, pinned
> threads,priority inheritance and the IPIs in the mix make correct and
> efficient hyperthreading safe scheduling difficult.
> This also looks like a lot of work and I am wondering if it would not be
> better spend on other scheduler improvements.

If nobody wants to do this, then we could always just keep on telling our
users "sorry, hyperthreading is broken on multi-user systems".  I don't
mind, personally -- I only have one system with a hyperthreaded cpu, and I
have hyperthreading turned off for performance reasons. :-)

Colin Percival



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?428FFBB8.5010201>