[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

This patch adds a config option to allow disabling hyper-threading by
default, and a kernel command line option to changes this default at
boot time.

Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
 Documentation/kernel-parameters.txt |    3 +++
 arch/i386/Kconfig                   |    5 +++++
 arch/i386/kernel/cpu/common.c       |   29 +++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 6747384..2b68d6e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -600,6 +600,9 @@ and is between 256 and 4096 characters. 
 	hisax=		[HW,ISDN]
 			See Documentation/isdn/README.HiSax.
 
+	ht=		[HW,IA-32,SMP] Enable or disable hyper-threading.
+			Format: <on|off>
+
 	hugepages=	[HW,IA-32,IA-64] Maximal number of HugeTLB pages.
 
 	noirqbalance	[IA-32,SMP,KNL] Disable kernel irq balancing
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
index 8ff1c6f..b4a2461 100644
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -1185,6 +1185,11 @@ config X86_HT
 	depends on SMP && !(X86_VISWS || X86_VOYAGER)
 	default y
 
+config X86_HT_DISABLE
+	bool "Disable Hyper-Threading by default"
+	depends on X86_HT
+	default n
+
 config X86_BIOS_REBOOT
 	bool
 	depends on !(X86_VISWS || X86_VOYAGER)
diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c
index d9f3e3c..42d2361 100644
--- a/arch/i386/kernel/cpu/common.c
+++ b/arch/i386/kernel/cpu/common.c
@@ -482,6 +482,29 @@ void __cpuinit identify_cpu(struct cpuin
 }
 
 #ifdef CONFIG_X86_HT
+
+#ifdef CONFIG_X86_HT_DISABLE
+static int disable_ht __cpuinitdata = 1;
+#else
+static int disable_ht __cpuinitdata;
+#endif
+
+static int __init parse_ht(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	if (!memcmp(arg, "on", 2))
+		disable_ht = 0;
+	else if (!memcmp(arg, "off", 3))
+		disable_ht = 1;
+	else
+		return -EINVAL;
+
+	return 0;
+}
+early_param("ht", parse_ht);
+
 void __cpuinit detect_ht(struct cpuinfo_x86 *c)
 {
 	u32 	eax, ebx, ecx, edx;
@@ -492,6 +515,12 @@ void __cpuinit detect_ht(struct cpuinfo_
 	if (!cpu_has(c, X86_FEATURE_HT) || cpu_has(c, X86_FEATURE_CMP_LEGACY))
 		return;
 
+	if (disable_ht) {
+		printk(KERN_INFO  "CPU: Hyper-Threading disabled by default. Enable with ht=on\n");
+		smp_num_siblings = 1;
+		return;
+	}
+
 	smp_num_siblings = (ebx & 0xff0000) >> 16;
 
 	if (smp_num_siblings == 1) {
-- 
1.4.1

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Alan]

On Wed, 29 Nov 2006 23:26:05 -0500
Ben Collins <bcollins@ubuntu.com> wrote:

> This patch adds a config option to allow disabling hyper-threading by
> default, and a kernel command line option to changes this default at
> boot time.
> 
> Signed-off-by: Ben Collins <bcollins@ubuntu.com>

The description is wrong - this does not disable hyperthreading it merely
leaves one thread idle. I don't believe Intel have ever published a
procedure for truely disabling HT, but if you idle a thread you may want
to adjust the cache settings on a PIV (10.5.6 in the intel docs) and set
it to shared mode. Need to play more with what the bios does I guess.

So Ack but with the proviso it should say "Ignoring" or "Not using" not
"Disabling", because it does not do the latter and there seem to be
performance differences as a result

Acked-by: Alan Cox <alan@redhat.com>

Alan

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Siddha, Suresh B]

On Thu, Nov 30, 2006 at 11:06:11AM +0000, Alan wrote:
> On Wed, 29 Nov 2006 23:26:05 -0500
> Ben Collins <bcollins@ubuntu.com> wrote:
> 
> > This patch adds a config option to allow disabling hyper-threading by
> > default, and a kernel command line option to changes this default at
> > boot time.
> > 
> > Signed-off-by: Ben Collins <bcollins@ubuntu.com>
> 
> The description is wrong - this does not disable hyperthreading it merely
> leaves one thread idle.

How does this patch achieve that? All this patch does is not detecting the
sibling topology. Kernel will still use all the threads and it just
forgoes the intelligence of which cpus are thread and core siblings and
thus disables the optimizations done by scheduler and doesn't export the
cpu topology to the user through sysfs and /proc.

Am I missing the point of this patch?

thanks,
suresh

> I don't believe Intel have ever published a
> procedure for truely disabling HT, but if you idle a thread you may want
> to adjust the cache settings on a PIV (10.5.6 in the intel docs) and set
> it to shared mode. Need to play more with what the bios does I guess.
> 
> So Ack but with the proviso it should say "Ignoring" or "Not using" not
> "Disabling", because it does not do the latter and there seem to be
> performance differences as a result
> 
> Acked-by: Alan Cox <alan@redhat.com>

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Pavel Machek]

Hi!

> This patch adds a config option to allow disabling hyper-threading by
> default, and a kernel command line option to changes this default at
> boot time.

> +config X86_HT_DISABLE
> +	bool "Disable Hyper-Threading by default"
> +	depends on X86_HT
> +	default n
> +

Command line options are fine, but additional config options mirroring
command line functionality look ugly to me...

							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 13:29 +0000, Pavel Machek wrote:
> Hi!
> 
> > This patch adds a config option to allow disabling hyper-threading by
> > default, and a kernel command line option to changes this default at
> > boot time.
> 
> > +config X86_HT_DISABLE
> > +	bool "Disable Hyper-Threading by default"
> > +	depends on X86_HT
> > +	default n
> > +
> 
> Command line options are fine, but additional config options mirroring
> command line functionality look ugly to me...

There's actually two parts to the patch. One is the kernel command line
option to allow HT to be enabled/disabled. The second is this config
option that allows the default to be off instead of the current
always-on.

The idea is that we want our users to be able to use hyper-threading,
but we don't want it on by default.

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Arjan van de Ven]

> 
> The idea is that we want our users to be able to use hyper-threading,
> but we don't want it on by default.

Hi,

can I ask why not?

Greetings,
   Arjan van de Ven
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 15:32 +0100, Arjan van de Ven wrote:
> > 
> > The idea is that we want our users to be able to use hyper-threading,
> > but we don't want it on by default.
> 
> Hi,
> 
> can I ask why not?

I'm just basing this on the history of the patch, which preceeds me, so
if this is incorrect, please don't blame me for misinformation :)

The original patch claims that hyper-threading opens the user up to some
sort of security risk involving hardware limitations in protecting
memory across the threads. I can't recall all the details.

If this is wrong, I'm more than happy to just drop the whole damn patch.

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Arjan van de Ven]

> I'm just basing this on the history of the patch, which preceeds me, so
> if this is incorrect, please don't blame me for misinformation :)
> 
> The original patch claims that hyper-threading opens the user up to some
> sort of security risk involving hardware limitations in protecting
> memory across the threads. I can't recall all the details.
> 
> If this is wrong, I'm more than happy to just drop the whole damn patch.

that is not correct.
I suspect what is meant is the "attack" on older openssl versions where
you could in theory get SOME information about a key in use by snooping
cache patterns in a shared cache situation. By no means is it a "direct"
leak of any kind, and openssl has since then been fixed to not have as
many key-dependent execution streams anymore.

I would suggest you drop the patch; openssl has been long fixed, and it
was only a theoretical attack in the first place...
I'm not saying the attack isn't something that should be addressed.. but
it is, and disabling hyperthreading is not the right fix.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Ben Collins]

On Fri, 2006-12-01 at 17:10 +0100, Arjan van de Ven wrote:
> > I'm just basing this on the history of the patch, which preceeds me, so
> > if this is incorrect, please don't blame me for misinformation :)
> > 
> > The original patch claims that hyper-threading opens the user up to some
> > sort of security risk involving hardware limitations in protecting
> > memory across the threads. I can't recall all the details.
> > 
> > If this is wrong, I'm more than happy to just drop the whole damn patch.
> 
> that is not correct.
> I suspect what is meant is the "attack" on older openssl versions where
> you could in theory get SOME information about a key in use by snooping
> cache patterns in a shared cache situation. By no means is it a "direct"
> leak of any kind, and openssl has since then been fixed to not have as
> many key-dependent execution streams anymore.
> 
> I would suggest you drop the patch; openssl has been long fixed, and it
> was only a theoretical attack in the first place...
> I'm not saying the attack isn't something that should be addressed.. but
> it is, and disabling hyperthreading is not the right fix.

Thanks for clearing that up. Patch withdrawn.

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Linus Torvalds]

On Fri, 1 Dec 2006, Arjan van de Ven wrote:
> 
> I would suggest you drop the patch; openssl has been long fixed, and it
> was only a theoretical attack in the first place...
> I'm not saying the attack isn't something that should be addressed.. but
> it is, and disabling hyperthreading is not the right fix.

I concur. A lot of these "timing attacks" may be slightly easier on HT 
CPU's than other CPU's, but they are still pretty damn theoretical (the 
more recent branch predictor one is even more so, since it apparently 
requires access to the branch predictor state itself, which you need 
CPL0 to get - and once you have CPL0, why the hell bother with the branch 
predictors at all, since you might as well just read the state directly 
from the process..)

People are a hell of a lot better at worrying about unrealistic attacks 
that they don't understand and thus sound scary, than about worrying about 
the simple things ("You mean my password shouldn't be my pets name, taped 
to my monitor? Really? And I wasn't supposed to give it out just because 
that nice man gave me chocolate?")

So I think people have blown those SSL timing attacks _way_ out of 
proportion, just because it sounds technical and cool. 

Besides, most of the time you can disable HT in the BIOS, which is better 
anyway if you don't want it.

		Linus

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Alan]

> So I think people have blown those SSL timing attacks _way_ out of 
> proportion, just because it sounds technical and cool. 
> 
> Besides, most of the time you can disable HT in the BIOS, which is better 
> anyway if you don't want it.

Agreed - but the SSL thing is an irrelevance. The main reason for
disabling HT (especially on a single core CPU) is because a lot of
workloads run faster with HT *off*.

Alan

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Mark Rustad]

On Dec 1, 2006, at 10:56 AM, Alan wrote:
>> So I think people have blown those SSL timing attacks _way_ out of
>> proportion, just because it sounds technical and cool.
>>
>> Besides, most of the time you can disable HT in the BIOS, which is  
>> better
>> anyway if you don't want it.
>
> Agreed - but the SSL thing is an irrelevance. The main reason for
> disabling HT (especially on a single core CPU) is because a lot of
> workloads run faster with HT *off*.

Yes. Another way to effectively turn it off is to set maxcpus to the  
number of physical cpus in your system. So far I have not encountered  
a system that that approach does not work on.

-- 
Mark Rustad, MRustad@mac.com

Re: [PATCH 1/4] [x86] Add command line option to enable/disable hyper-threading.

[Peter Cordes]

 (I'm not subscribed to the list, so this message looks like a normal reply,
but it isn't.  I didn't try to hack up an In-Reply-To: header...)

On Dec 1 2006, Linus Torvalds wrote:
>On Fri, 1 Dec 2006, Arjan van de Ven wrote:
>>
>> I would suggest you drop the patch; openssl has been long fixed, and it
>> was only a theoretical attack in the first place...
>> I'm not saying the attack isn't something that should be addressed.. but
>> it is, and disabling hyperthreading is not the right fix.
>
>I concur. A lot of these "timing attacks" may be slightly easier on HT
>CPU's than other CPU's, but they are still pretty damn theoretical (the
>more recent branch predictor one is even more so, since it apparently
>requires access to the branch predictor state itself, which you need
>CPL0 to get - and once you have CPL0, why the hell bother with the branch
>predictors at all, since you might as well just read the state directly
>from the process..)

 I recently read the paper by Aciicmez, Koc, and Seifert.
http://eprint.iacr.org/2006/351 (full text PDF available; It's a fairly
interesting read, with some background and overview of this kind of attack).

 They have a clever method for gathering information about the branch
predictor state, to attack one particular branch in the RSA code, which is
taken or not depending on the key bit.
- RSA and the attacker thread run on the same physical CPU.

- The attacker thread runs a loop that contains enough branches to ensure the
  branch being attacked is flushed from the branch target buffer.  Thus the
  CPU has to speculate that it's not taken.  If that's the case, then
  nothing special happens.

- If the branch is taken, then one of the attack loop's branches is evicted
  from the BTB.  When the attack loop hits that misprediction, it causes a
  cascade of mispredictions and BTB evictions, leading to a change in loop
  execution time greater than the noise.  They have plots showing some good
  runs and some noisier runs...

- That gives them enough resolution to get most of the key bits in a single
  run, so they don't have to average over multiple runs with the same input
  data.

- They attacked 512bit keys on OpenSSL 0.9.7e, with some modifications to
  make it simpler.  It's unclear from their wording whether they attacked
  both their simplified and the original, or if both their versions (with
  and without a balanced Montgomery powering ladder) were the result of
  modifying OpenSSL.

>So I think people have blown those SSL timing attacks _way_ out of
>proportion, just because it sounds technical and cool.

 I think this attack is technical and cool, regardless of whether it's
useful in the real world.  Obviously it requires running custom code on the
same machine as the process under attack, which can't happen in a lot of
server applications.  It could be effective against SSH on a multi-user
machine, though.

>Besides, most of the time you can disable HT in the BIOS, which is better
>anyway if you don't want it.

 If someone is trying to find a way to turn off HT, for security or
performance, it's better if they have to do it in a way that doesn't hurt
performance.  I don't like options that look useful but when you read the
fine print turn out to be non-optimal.

 If there was support for actually setting up the CPU the same way BIOSes do
when you HT is disabled that way, that would be cool.  It's always nice to
be able to change things without walking down to the machine room to get a
console on our cluster that doesn't have remote access to the BIOS setup.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC