Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

mdsattacks.com

Post reply on HN
Print view View original

101–110 of 118 posts

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#101

Post by mmastrac »

cperciva wrote: post #96
ivl wrote: post #74

Earlier quoted context omitted.

Decade and a half, even. If I remember right, the first CVE for an HT security flaw was summer 2005.

I announced it publicly 14 years ago yesterday.

This one? https://nvd.nist.gov/vuln/detail/CVE-2005-0109

Dang: "Hyper-Threading technology, as used in FreeBSD and other operating systems that are run on Intel Pentium and other processors, allows local users to use a malicious thread to create covert channels, monitor the execution of other threads, and obtain sensitive information such as cryptographic keys, via a timing attack on memory cache misses."

Also, found elsewhere:

"According to Linus Torvalds and others on linux-kernel this is a theoretical attack, paranoid people should disable hyper threading"

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#102

Post by cperciva »

mmastrac wrote: post #101
cperciva wrote: post #96

Earlier quoted context omitted.

I announced it publicly 14 years ago yesterday.

This one? https://nvd.nist.gov/vuln/detail/CVE-2005-0109 Dang: "Hyper-Threading technology, as used in FreeBSD and other operating systems that are run on Intel Pentium and other processors, allows local users to use a malicious thread to create covert channels, monitor the execution of other threads, and obtain sensitive information such as cryptographic keys, via a timing attack on memory cache misses." Also, found…

Yes. Intel dismissed it at the time, saying that "nobody would ever have untrusted code running on the same hardware on which cryptographic operations are performed".

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#105

Post by pertymcpert »

beagle3 wrote: post #89
pertymcpert wrote: post #79

Earlier quoted context omitted.

What do you think is a good performance improvement then?

(and to the two other responses) If your workload is already well parallelized, then, yes 20% is quite significant. However, working to parallelize properly over 8 rather than 4 has its own costs. The thing that bothers me most is that 800% CPU and 500% CPU on this processor are roughly equivalent at 5x100%CPU, it makes everything very hard to reason about when planning capacity.

I think you’re misunderstanding what HT is. It’s not true parallelism, it’s just hiding latency by providing some extra superscalar parallelism. You can’t expect it to give you actual linear improvements in performance because it’s just an illusion.

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#106

Post by astrange »

api wrote: post #72
penagwin wrote: post #45

Earlier quoted context omitted.

That would make sense, my understanding is that with a 100% pegged CPU hyperthreading won't be super beneficial as they aren't real cores, just smarter scheduling. You can't really schedule 100% load better, however for applications that are latency specific it would make more sense, as you don't have the CPU pegged, you just want a faster response.

> You can't really schedule 100% load better Sure you can. You can do math while another HT is waiting for memory. Sometimes you can even multiplex use of multiple ALUs or one HT can do integer and another can do floating point. It's actually under high multithreaded load that HT shines, especially if that load is heterogenous or memory latency bound.

Wouldn't hyperthreading also be more power-efficient compared to running a second core?

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#107

Post by Rafuino »

fakwandi_priv wrote: post #87
Rafuino wrote: post #43

Better Intel page on the MDS vulnerability is here: https://www.intel.com/content/www/us/en/architecture-and-tec... . Interesting point: "MDS is addressed in hardware starting with select 8th and 9th Generation Intel® Core™ processors, as well as the 2nd Generation Intel® Xeon® Scalable processor family." Looks like my 8700K isn't on the list though.

According to the researchers in the paper[0] this is not true. >We have verified that we can leak information across arbitrary address spaces and privilege boundaries, even on recent Intel systems with the latest microcode updates and latest Linux kernel with all the Spectre, Meltdown, L1TF default mitigations up (KPTI, PTE inversion, etc.). In particular, the exploits we discuss below exemplify leaks in all the rele…

I searched the the paper and it doesn't seem to falsify what I linked to, but I'll have to dig deeper into the research. "Recent Intel systems" isn't specific enough.

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#108

Post by beagle3 »

pertymcpert wrote: post #105
beagle3 wrote: post #89

Earlier quoted context omitted.

(and to the two other responses) If your workload is already well parallelized, then, yes 20% is quite significant. However, working to parallelize properly over 8 rather than 4 has its own costs. The thing that bothers me most is that 800% CPU and 500% CPU on this processor are roughly equivalent at 5x100%CPU, it makes everything very hard to reason about when planning capacity.

I think you’re misunderstanding what HT is. It’s not true parallelism, it’s just hiding latency by providing some extra superscalar parallelism. You can’t expect it to give you actual linear improvements in performance because it’s just an illusion.

I understand that very well. But non of the standard tools that manage CPU understand that, and most people don't either.

If I had a nickel for every time I had to explain why "You are at 50% CPU now, but you can't actually run twice as many processes on this machine and get the same runtime", I'd be able to buy a large frapuccino or two at starbucks.

Perhaps I'm uninformed though - is there a tool like htop, which would give me an idea of how close am I to maxing out a CPU?

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#109

Post by ajdlinux »

api wrote: post #72
penagwin wrote: post #45

Earlier quoted context omitted.

That would make sense, my understanding is that with a 100% pegged CPU hyperthreading won't be super beneficial as they aren't real cores, just smarter scheduling. You can't really schedule 100% load better, however for applications that are latency specific it would make more sense, as you don't have the CPU pegged, you just want a faster response.

> You can't really schedule 100% load better Sure you can. You can do math while another HT is waiting for memory. Sometimes you can even multiplex use of multiple ALUs or one HT can do integer and another can do floating point. It's actually under high multithreaded load that HT shines, especially if that load is heterogenous or memory latency bound.

I too was once under the misapprehension that HT was "just smarter scheduling", until I took a university course in microarchitecture that explained how Simultaneous Multithreading actually works in terms of maximising utilisation of various types of execution units. I wonder why "smarter scheduling" became a common understanding.

Re: MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs

#110

Post by erk__ »

ghettoimp wrote: post #97
api wrote: post #71

Earlier quoted context omitted.

There are probably fewer than 1000 people in the world capable of finding these kinds of vulnerabilities. Sounds about right to have 10 at Intel.

Out of curiosity, where would the others be?

Universities, three letter agencies and private or government actors. At least I would guess that, maybe also a bunch at anti virus developers.
Post reply on HN