Broadband Tech > Security > Security > "HyperThreading considered harmful"

"HyperThreading considered harmful"

So if this is indeed true,can it be fixed, being a piece hardware thats flawed? If not...i want my money back on all the dual core xeons I have.
Bummer.

reply to Steve
Interesting and even with planetary alignment not impossible to achieve

from vendor statements it looks some action will be/is taken
»www.daemonology.net/hyperthreadi···harmful/

Cudni
--
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
Help yourself so God can help you..it does exactly what it says on the sig

reply to Steve
My head is spinning!

Interesting, though headache-inducing, read!

reply to ironwalker
I think this is really nothing to worry, though I'm not any kind of hardware security expert.

Unless I'm reading it wrong, it requires that the high-security thread and the low security thread be running at the same time, and this looks like a really hard thing to coordinate. User programs have only limited ability to interact with the scheduler, and I don't think they have any way of requesting "Run me at the same time you run $PROCESS".

I won't go farther than "It looks like a stretch to me", because all kinds of clever people have come up with all kinds of clever ideas to do surprising things.

But the "vendor notifications" seem a little weak to me, like "Well, this is nothing but I guess we have to say something"

reply to Steve
Thanks all,I read further and what cudini provided and I should be fine.The fix for FreeBSD was taken care of already.

reply to Steve
wel steve it may also be possible for a remopte user to do the same. Example run a java app on web site that stays active. Then you might be able to exploit the flaw remotly. And take your pick of other threads. It would be hard as hell but probably doable. Ive never delt with a hardware securit flaw before. But getting a buffer over run is similar to a hardware security flaw realy. Essentialy what your doing is putting things in to ram area from one programs area to another programs area of ram. So it should be at least possible to do the same with a cpus cache.
--
DSLR security chat at us.ausirc.net chanel #dslr_sec lets pack this channelopen source dns server for *nix and windows »powerdns.com

just used as a example. It how ever is probably possible to do so with spyware torjans or other apps you could trick the user in to downloading. And i only read part of it. Before posting reading more now. Ither way intel needs to take serious action to correct it.
--
DSLR security chat at us.ausirc.net chanel #dslr_sec lets pack this channelopen source dns server for *nix and windows »powerdns.com

reply to Steve

reply to Steve
Don't forget to turn off file system caching. The file system cache can be used as a covert channel.

In fact, almost anything can be used as a covert channel.

reply to Steve
Perhaps that's why the 'J' chip was introduced, have no idea what happens with the 600 series though? Noticed the rather well done document that was linked, but that was before the aforementioned 500 'J' series.

»www.intel.com/cd/ids/developer/a···9308.htm

Cheers
--
2.66g/533fsb Intel CPU @ 3.48g512meg Twinmos PC3700~466 DDR @ 2.8v -PCpower&Cooling 512.ATI 9500 Pro @ 9700 Pro @1.6v--AMD ASUS A7N8X-E ~2500+ @3200 ATI 9500 Pro, Corsair 512LL.-- Aristotle.net

reply to Steve
I smell revenue opportunity!

reply to Steve

reply to Steve
Ive been thinking of updating to about 3.4 and good memory, but it doesn't help the sales pitch thats for sure
seeing as the 2.8 i have has negligable cache to say the least

its been obvious for a while about hardware firewalling: so in return does intel call back the so called bad chips i think not...

maybe it is time intel pulled their finger out if they want to knock back AMD and the new firewalled motherboard , but thats another question altogether, what would the 2 do together, a 2 tier firewall, bring on the detection system, it has long been a second thought ,what if you produce something that defends its self

as they seem to be going dual chip, what about 10 or 20 chips/processors, they still need a controller, maybe it should be on a separate pattern and if the user presets dont match, or keypad style install process,finger print install

but i remember a thread about about security chips here somewhere, but it always needs to be held by the owner, its everyone's basic right, software gives you a key to the program to run , why cant a chip use some principle to stop any external commands, just make the ad, a pack you can download that is clean but advertises, they could make more money out of it legal than illegal, but i guess if we dont have our toys, the ego hurts

reply to Steve
from
»www.securityfocus.com/archive/1/···-05-17/0
"..
IV. Workaround

Systems not using processors with Hyper-Threading Technology support are
not affected by this issue. On systems which are affected, the security
flaw can be eliminated by setting the "machdep.hlt_logical_cpus" tunable:

# echo "machdep.hlt_logical_cpus=1" >> /boot/loader.conf

The system must be rebooted in order for tunables to take effect.

Use of this workaround is not recommended on "dual-core" systems, as
this workaround will also disable one of the processor cores.

V. Solution

Disable Hyper-Threading Technology on processors that support it.

NOTE: It is expected that future work in cryptographic libraries and
operating system schedulers may remedy this problem for many or most
users, without necessitating the disabling of Hyper-Threading
Technology. Future advisories will address individual cases. ..."

Cudni
--
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
Help yourself so God can help you..it does exactly what it says on the sig

reply to ironwalker
Looks like a bad premise dressed up in a lot of confusing language.
--
Pure magic in 2k of 6502.

reply to Steve
The dodgy part of the premise is that you're executing malicious code on your hyperthreaded machine.

OK, so _if_ you've got malware then your crypto keys can be deduced via cache interference, given a suitable skilled malware author.

On the other hand, if you've got malware, I suspect that from a practical point of view, there are easier ways it could steal your keys.

Cache interference sounds like a last-resort attack for a bad guy who can't find any easier software bugs to exploit. Oh for that day to arrive!

In other words, you should worry about the more likely attacks first.

(On the other hand, this is way more interesting to read about that some stupid bug made by a careless programmer).