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>