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

71–80 of 118 posts

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

#71

Post by api »

thijser wrote: post #22

In a Dutch article ( https://nos.nl/artikel/2284630-nederlanders-vinden-beveiligi... ), one of the researchers says "het aantal mensen bij bedrijven als Intel die zich op dit niveau met beveiliging bezighoudt, is echt op de vingers van twee handen te tellen." = There are 10 or fewer people working on security at this level at companies like Intel. This sounds very hard to believe to me. With the previous attacks ther…

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.

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

#72

Post by api »

penagwin wrote: post #45
silversconfused wrote: post #24

Earlier quoted context omitted.

I've seen this claim made for routers and other low intensity low latency workloads.

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.

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

#73

Post by api »

kccqzy wrote: post #69
gambler wrote: post #14

It seems that we need to move away from clever, complicated low-level micro-optimizations that rely on mangling instructions and just use more cores. That should allow for simpler security model.

There are plenty of scenarios where synchronization overheads between cores dwarf the performance gain, but OoO execution can help. But maybe instead of having more cores, we should expose the different execution units within a CPU core to the architectural level? That however brings back memories of Itanium, and the general fact that compilers just can't do static scheduling well enough.

I've started to think Itanium might have been sort of on the right track but ahead of its time and in some ways poorly executed.

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

#74

Post by ivl »

StudentStuff wrote: post #3

Hyper-Threading has been a source of security concerns for a decade now, and vulnerabilities in existing HT implementations have been trickling out over the last few years. Unlike Management Engine or TrustZone, at least we can disable Hyper-Threading (for a 30% performance hit).

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

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

#75

Post by iddqd »

PureParadigm wrote: post #38
Wowfunhappy wrote: post #25

Earlier quoted context omitted.

I'd really like to be given a choice, at least. My gaming PC is used exclusively for gaming, so it needs to be performant, but does not need to be secure.

If running Linux you can disable the meltdown/spectre mitigations with the nopti option [1]. 1. https://yux.im/posts/technology/security/disable-meltdown-an...

Here is a similar windows tool: https://www.grc.com/inspectre.htm

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

#76

Post by DeepYogurt »

silversconfused wrote: post #35
Theodores wrote: post #19

It is funny how ChromeOS is the most ridiculously secure of the commonly available operating systems. It is not as if you can do much other than surf the internet with it. It makes me chuckle to think that my not-so-computer-literate friend whom I gave a Chromebook to is protected from anyone snooping in on Youtube, Hotmail and Youtube running on this toy machine (designed for 9 year olds). There really is nothing to…

Hyper threading was an intel stop-gap reaction to the athalon64 x2, which was a REAL dual core, to buy them time while the pentium D was created and later laughed off the market. We finally got an "OK" dual core from intel when they decided to hack pentium 3 cores together and call it the Core duo, and with the core 2 duo they finally caught back up to AMD (by hacking amd64 instructions onto the P3 cores) and were ab…

> Hyper threading was an intel stop-gap reaction to the athalon64 x2

No. Hyper threading was introduced in Feb 2002. The original single core athlon 64 was Sept 2003. The x2 was 2007.

https://en.wikipedia.org/wiki/Hyper-threading

https://en.wikipedia.org/wiki/Athlon_64

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

#77

Post by Morgawr »

temac wrote: post #51
kmfrk wrote: post #23

Earlier quoted context omitted.

It was discovered June last year according to this timeline, so a lot of people must've successfully kept mum for a long time: https://mdsattacks.com .

Maybe we should start to seriously question the value of so long embargos. This is coordinated disclosure; if the vendor refuses reasonable coordination (and it seems Intel does, with such delays, and also because it stills silos the security researchers way too much), then fuck them and publish (probably not immediately but certainly not after a year...) It seems that broadly the same principles have been found inde…

It really depends. Think about it this way, would you rather have an undisclosed vulnerability go untreated and undetected (as far as everyone knows) for an extra year, or suddenly disclose it to the rest of the world before all major interested parties (big companies, chip vendors, etc) have workarounds and mitigations techniques, so actual malicious attackers can exploit it before the countermeasures are ready?

In an ideal world, you should disclose everything and let everyone know so they can take measures against it, but in reality there might be less damage to let the vulnerability continue stay undetected for a few more months while everyone else plans to patch it and release such fixes as it gets disclosed.

I do agree that almost a whole year is, however, a very long time though.

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

#78

Post by consp »

temac wrote: post #51
kmfrk wrote: post #23

Earlier quoted context omitted.

It was discovered June last year according to this timeline, so a lot of people must've successfully kept mum for a long time: https://mdsattacks.com .

Maybe we should start to seriously question the value of so long embargos. This is coordinated disclosure; if the vendor refuses reasonable coordination (and it seems Intel does, with such delays, and also because it stills silos the security researchers way too much), then fuck them and publish (probably not immediately but certainly not after a year...) It seems that broadly the same principles have been found inde…

considering the june/july initial reporting, the stacking of evidence to related exploits and the release in may next year it look more like 9 months plus some slacking due to multiple being reported. Does not sound like a "they kept waiting indefinitely" but more like proper due diligence.

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

#79

Post by pertymcpert »

beagle3 wrote: post #18
StudentStuff wrote: post #3

Hyper-Threading has been a source of security concerns for a decade now, and vulnerabilities in existing HT implementations have been trickling out over the last few years. Unlike Management Engine or TrustZone, at least we can disable Hyper-Threading (for a 30% performance hit).

Also, HT is not such a great performance win - on a few different 4-core/8-thread machines, I had access to, loading all 8 threads to "100% CPU" (whatever that means) usually only delivers 20-30% faster computation than with HT off (4-core/4-thread) - which is inline with your 30% number. And that's an improvement - some 15 years ago, with similar computational loads, most of my tests ran 10-20% faster with the HT of…

What do you think is a good performance improvement then?

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

#80

Post by jchw »

wyldfire wrote: post #28
titzer wrote: post #2

There are 4 separate vulnerabilities in MDS, not just the one reported in the ZombieLoad paper. They each have CVEs. Chrome Browser response here: https://www.chromium.org/Home/chromium-security/mds

> Linux users should apply kernel and CPU microcode updates as soon as they are available from their distribution vendor, and follow any guidance to adjust system settings. Canonical says that they have those for 14/16/18.04 [1]. But possibly more interesting is the fact that this disclosure has been so well synchronized. How do the relevant players decide what the threshold is for informing other tech companies? How…

Well, practice makes perfect... by 2020 the process of disclosing CPU vulnerabilities should be pretty streamlined, if the pace doesn’t slow down.
Post reply on HN