• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

HT harmful----?

"Administrators of multi-user systems are strongly advised to take action to disable Hyper-Threading immediately; single-user systems (i.e., desktop computers) are not affected." .

as quoted from the link on the [H] front page. Looks like it doesn't affect me.



LKS
 
I'm an assembly programmer, but I have no idea how they want to make one thread 'eavesdrop' on the other.

The only thing I can think of is that Intel didn't make two copies of the memory protection logic, which would mean that one thread can poke inside the other thread's memory, even if the second thread is owned by a different process...
But I just can't imagine Intel overlooking something that obvious...
Sadly there doesn't seem to be any technical info on what they do, or how.
 
The theory so far is that it would take a compromised system (trojan running) to monitor another thread and steal data running in other processes from registers or caches. IMO, this is way overblown. It is possible to "snoop" the caches, even in HT processes. That's the vulnerability.

The only *general* problem I see is on a shared server where 1 task can spy on other virtual servers.

Windows isn't mentioned on that guy's page. I wonder if that is unintentional or because it's not a problem when running Windows (i.e. passwords/key decryption results aren't stored in memory in plain text). That would be a huge omission because 1 in 5 web servers is a Microsoft server (over 50% Fortune 1000 companies use MS web servers) and 55% of all servers are MS.
 
Two work arounds for the problem have been suggested and both will cripple HT:

1) Patch the OS to only run threads from the same process at the same time. Since a process shares all its memory with its threads, it is safe to run two threads from the same process at once. This fix would also mean that two threads from two different processes would not be allowed to run at once; forget about encoding and gaming or encoding and browsing, or much of anything else for that matter.

2) Flush the cache, TLB, etc during a context switch. This would fix the security issues, but it's going to make HT so slow it won't even be worth using. The advantage of HT is letting two threads share the CPU. If OS cleared out all the buffers each time a thread wanted to use the logical processor, the whole point of HT would be killed.

It looks like the HT advantage is going to be killed for everything but home use.
 
well after reading the paper, i think this is WAY overblown.
his example bascially boils down to this:

with alot of work and guesswork, you can reasonably expect to get 310 bits out of a 512bit encryption key, from spying on the cache. this is FAR more difficult to implement in a real world situation than people might think. You would have to know which security based program to look for, know exactly when its using the cache, and if your lucky, get maybe half the bits out of it.

yeah, they should fix it, but I wouldnot bother shutting down HT all over the planet...silly
 
Steel Chicken said:
the guy updated his site with a paper, check it out
http://www.daemonology.net/papers/htt.pdf
Click to expand...
Interesting paper. It looks like the particular OpenSSL problems can be fixed without disabling HT.

Intel probably won't fix this until someone decides to hack the microcode update procedure using a similar method. ;) That's Intel's prime secret.
 
pxc said:
Intel probably won't fix this until someone decides to hack the microcode update procedure using a similar method. ;) That's Intel's prime secret.
Click to expand...

im not following, you can already upload custom microcode via the linux kernel...are you talking about something else?
 
Steel Chicken said:
im not following, you can already upload custom microcode via the linux kernel...are you talking about something else?
Click to expand...
It comes as a binary driver. There is no source for it.

A real hack may allow alternate multipliers, HT and even EM64T to be enabled on many processors.
 
pxc said:
It comes as a binary driver. There is no source for it.

A real hack may allow alternate multipliers, HT and even EM64T to be enabled on many processors.
Click to expand...

ive done a little bit of disassembly (but im far from an expert)...whats to keep people from disasemmbling it step by step?
 
2 reasons: it's possible to disable step by step debugging with many free and commercial programs, especially on one that runs that ring 0 with timing and state critical code, and disassembly doesn't always show *how* the code runs.

Yeah, you can disassemble a tiny binary and trace through it. Now try that with a 100KB binary that purposely hides how it works without the abilty to use a step by step debugger. :p
 
pxc said:
2 reasons: it's possible to disable step by step debugging with many free and commercial programs, especially on one that runs that ring 0 with timing and state critical code, and disassembly doesn't always show *how* the code runs.

Yeah, you can disassemble a tiny binary and trace through it. Now try that with a 100KB binary that purposely hides how it works without the abilty to use a step by step debugger. :p
Click to expand...

not debug. just a dissasembly.
but yeah, it would be a major undertaking. But if its "Intels biggest secret" it certainly wouldnot be impossible.
 
Steel Chicken said:
with alot of work and guesswork, you can reasonably expect to get 310 bits out of a 512bit encryption key, from spying on the cache. this is FAR more difficult to implement in a real world situation than people might think. You would have to know which security based program to look for, know exactly when its using the cache, and if your lucky, get maybe half the bits out of it.

yeah, they should fix it, but I wouldnot bother shutting down HT all over the planet...silly
Click to expand...
I think you underestimate how important 310 bits really is. By cutting more than half of the bits out of the key, you have just made a HUGE step towards cracking the whole thing. 512bits -> 202bits is no small thing.

But you're right. There is no reason to turn off HT all over the world. I think any sysadmin would be wise to do so on any server that has valuable/secret data on it. On the other hand, I see no reason why someone should feel the need to turn it off on the average desktop.
 
visaris said:
There is no reason to turn off HT all over the world. I think any sysadmin would be wise to do so on any server that has valuable/secret data on it.
Click to expand...

Why? If someone is able to run a cache sniffer on your box, then you're already owned. It won't matter if you've got HT or not -- somoeone is running arbitrary code on your box.
 
mikeblas said:
Why? If someone is able to run a cache sniffer on your box, then you're already owned. It won't matter if you've got HT or not -- somoeone is running arbitrary code on your box.
Click to expand...

+1
if someone can run arbitray code on one of my servers, the LAST thing im worried about is cache sniffing.
 
Thanks for posting the link.

The paper seems to assume that nothing else is happening on the machine... at all. Aside from the spy process and the process being observed, there's also the operating system itself. When it decides to context switch, then it's running code and touching memory, which disrupts the state of the cache.

The author doesn't seem to explicitly incorporate this in his analysis. I guess it is one of the things that contributes to his predicted bit error rate.

The same problem exists in his assumptions about the macro version of the covert channel: that the OS won't predictively or preemptively swap in one of the pages of memory used by the other process and disrupt the measurements.

One of the assertions the author makes in a footnote (#3, on page 3 ) is interesting to me:

By default, cache lines are tagged according to which thread "owns" them and cannot be accessed by the other thread; this behaviour may be modified by the operating system, but only to the extent of allowing cache line sharing between threads when the same paging tables, and such threads can already communicate."
Click to expand...

Certainly, he must mean "core" when he says "thread", since I don't think an operating system thread can possibly be tagging ownership of a cache line. I don't understand the relationship between the cache lines and the page tables; where can I read more about that? What happens if a core touches memory that would cause it to hit a cache lines that is tagged to the other core? It's necessarily a cache miss?

I noticed something else interesting.
 
Why? If someone is able to run a cache sniffer on your box, then you're already owned. It won't matter if you've got HT or not -- somoeone is running arbitrary code on your box.
Click to expand...
-1
How so? The server running at my work has 100s of users. Any one of them could be smarter than me, or just a script-kiddie. Any one of them can run executables on the server. That being said, we don't have much in the way of secret critical data. So, for us, the HT bug in a non-issue.

Make no mistake: Just because you don't run a server with thousands of users doesn't mean that no one does. Just because you don't know how to exploit this, doesn't mean that other people will not be able to. For many down at ORNL (Oak-Ridge Nation Labs, you know, where they design NUKES and do other top-secret research), this could have HUGE implications.

Just throwing this issue aside and saying: "loL, iF SOme0Ne can rUn a prograM on UR BOx you HaVE bigger Pr0blems!! lol!" Is just stupid. Try looking a little further out than your little P4 box you use to play games.

EDIT:
Gah, again, I always come across as being a little mean. I don't really intend to. Again, the point is that this does matter, and to quite a few people. I think you would be better off thinking about what this could really mean to the world than comming up with intel-fan-boy, cop-out answers and excuses about how it doesn't matter.
 
visaris said:
-1
How so? The server running at my work has 100s of users. Any one of them could be smarter than me, or just a script-kiddie. Any one of them can run executables on the server. That being said, we don't have much in the way of secret critical data. So, for us, the HT bug in a non-issue.
Click to expand...

allowing users to run executables ON the server?
Yikes. You got balls of steel.
 
visaris said:
-1
How so? The server running at my work has 100s of users. Any one of them could be smarter than me, or just a script-kiddie. Any one of them can run executables on the server.
Click to expand...

If any user can run arbitrary code on those servers, how do you secure them? Anything the user runs can be a DOS attack. Here's sample code for a C++ DOS applicable to a system where arbitrary code may be executed:

Code: 
int n = 0;
while (1) n++;

It sucks all the CPU it can, making response for other users slow and sluggish... up to the limits for priority and consumption exist on the process (or user) where it's running.

The issue of code ownership applies whether you've got Hyperthreading enabled or not; wether you're running Intel processors or AMD processors.

visaris said:
Just throwing this issue aside and saying: "loL, iF SOme0Ne can rUn a prograM on UR BOx you HaVE bigger Pr0blems!! lol!" Is just stupid.
Click to expand...

It isn't stupid: it's just logic. The paper itself says that the machine must be quiescent. What server is completely quiescent? Even if the machine has low load for a while, how can you install and run the spy program?

Even that withstanding, say you have some reason to allow users to run arbitrary code on your box. Being able to run the spying code at the same time as the process who's thread it wishes to is highly unlikely. And there's no way to guarantee it's happening or not -- assuming that you've got at least enough security to isolate these different users, the spy code has no idea at all what it is observing. In other words, it can't tell at all if it was successful or not.

Maybe you run the spyer. You get back what you think are 310 bits of key data. Or, maybe not: maybe they're just crap. How would you evel tell?

Say you want a two-tiered attack. You find some other way to inject code, through some other software security issue. Would you insert code that would go sniffing around in the processor cache? That must be the least effective way to make progress on the system, since you've got no idea what to go sniffing for, or when you've found it.

visaris said:
Gah, again, I always come across as being a little mean. I don't really intend to. Again, the point is that this does matter, and to quite a few people. I think you would be better off thinking about what this could really mean to the world than comming up with intel-fan-boy, cop-out answers and excuses about how it doesn't matter.
Click to expand...

All the things you've accused me of are completely inaccurate, and entirely inappropriate. Even the ones you included in the paragraph where you try to excuse your own clumsy response.
 
If any user can run arbitrary code on those servers, how do you secure them? Anything the user runs can be a DOS attack. Here's sample code for a C++ DOS applicable to a system where arbitrary code may be executed:

int n = 0;
while (1) n++;

It sucks all the CPU it can, making response for other users slow and sluggish... up to the limits for priority and consumption exist on the process (or user) where it's running.
Click to expand...
Yay, you can write two lines of C code. That proves nothing, and on top of this, the issue of a DOS attack has nothing to do with data security. You just throw this crap around to confuse the issue, which is data security. Servers frequently do allow users to run code, and on such servers, there is usually some idea of users and of permissions. One user should not be allowed to access data from another user (or another user's processes). This is not a hard concept. Again, I call BS on both of you. The argument that "OMG! users can run codE on teh server!" is just stupid no matter how you look at it. Again, look a little further than your desktop p4 you use for games. It's a big world out there.

... there's no way to guarantee it's happening or not ... Or, maybe not: maybe they're just crap. How would you evel tell? ... Being able to run the spying code at the same time as the process who's thread it wishes to is highly unlikely ...
Click to expand...
Lol, you're some security expert! I mean, after all, "It's not going to happen because it's hard to do!" What complete and total BS. Let's just say I'm glad you're not in charge of the US's 1,000+ user network at ORNL / any other site with important data.

1) The idea that a server which allows users to compile and run software is somehow "owned", is just dumb. The OS is built with support for users, groups, file and process permissions, etc, etc, etc. Any sever should be able to be locked down tight while still allowing users to run arbitrary code. The "Usars can RuN teh c0de!" is a dumb argument, again, however you look at it. End of story.

2) The it's hard to do so it's a non-issue is a valid argument I suppose. If something is hard enough, most people won't do it. That's great. But, there will always be something which is worth the trouble. Government secrets, a fortune-500 company's trade secrets, or anything else really valuable.
 
Bah, there I go being an ass again. Sorry mike. I know you're a smart guy. I just think this shouldn't be dismissed. Again, I don't want everyone to run to the data-center to turn off HT on all the boxes, but, that being said, there are cases where this could be an issue. Saying that this HT bug is not an issue on 90% of the boxes out there might be fair. It might even be fair to say 95%. Maybe even 99%. But the point is that this bug is going to be a _huge_ issue for a small number of people. Again, one shouldn't just say "it doesn't matter at all" and move on.
 
visaris said:
Again, one shouldn't just say "it doesn't matter at all" and move on.
Click to expand...

I can't figure out who you're quoting. Meanwhile, I give up: you're generating more heat than light.
 
You must log in or register to reply here.
Back
Top