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

61–70 of 118 posts

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

#61

Post by rightbyte »

compiler-guy wrote: post #11
rightbyte wrote: post #8

Earlier quoted context omitted.

The security concern is remote code execution via JS, and sharing processor time with other people you don't trust, right? It should be up to the VM-as-a-service and browser vendors to flush the cache properly.

No. The security concern is attackers reading data they shouldn’t. The article explains how. “Microarchitectural Data Sampling (MDS) is a group of vulnerabilities that allow an attacker to potentially read sensitive data.” That is way more serious than stealing cycles.

Ye, but I didn't understand how this was different than Spectre, except with different caches.

Still it's fine with no JS and no shared processor time, right?

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

#62

Post by [deleted] »

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...

[deleted]

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

#64

Post by berkut »

jandrewrogers wrote: post #29
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).

Disabling hyper-threading is highly unlikely to produce a 30% performance hit. Most highly optimized software disables or avoids hyper-threading because doing so increases performance. Hyper-threading tends to benefit the performance of applications that have not been optimized, and therefore presumably are also not particularly performance sensitive in any case.

In highly-parallel workloads like rendering (ray tracing) where pipeline stalls due to loads happen quite regularly, it's fairly easy to get 20-35% speedups with HT.

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

#65

Post by ajross »

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…

A 20-30% increase is a BIG increase for a hardware feature, though. The cost of hyperthreading in transistors mostly amounts to the larger total register set. The whole point is the rest of the decode/dispatch/execute/retire pipeline is all shared.

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

#66

Post by kccqzy »

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…

How is 20%-30% not a great performance win? If I tell you today there's this One Simple Trick that you can do on your computer to instantly gain access to 20%-30% more performance, would you do it in a heartbeat?

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

#67

Post by rurban »

tarlinian wrote: post #41
JdeBP wrote: post #16

Commentary by Intel: https://software.intel.com/security-software-guidance/softwa... Commentary by RedHat: https://www.redhat.com/en/blog/understanding-mds-vulnerabili... ( https://news.ycombinator.com/item?id=19912108 ) Commentary by Ubuntu: https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigat...

Some additional pages by Intel describing mitigation techniques for non-HT domains (including the new overload of the VERW instruction): https://software.intel.com/security-software-guidance/insigh... Details of which steppings of which processors are affected by which CVEs: https://software.intel.com/security-software-guidance/insigh...

They advise only to use lfence, similar to compiler vendors. I advise to use a full mfence instead when clearing secrets. Load/store ordering is violated in caches. And cleaning secrets is done not so often, it needs to be reliable. MDS is thanksfully only for small data, and modern keys are much larger. But adding a simple verw for the tiny non-cache buffers does not hurt either.

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

#68

Post by thijser »

baq wrote: post #47
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…

how much more would you expect? 10 people is pushing the two-pizza limit.

People don't necessarily need to be in one big team. Lots of things that are important can be worked on by more than 10 people. (Surely Google and Facebook each have more than 10 people working on security).

Is there evidence that so few people are working on security at Intel?

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

#69

Post by kccqzy »

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.

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

#70

Post by rurban »

rightbyte wrote: post #61
compiler-guy wrote: post #11

Earlier quoted context omitted.

No. The security concern is attackers reading data they shouldn’t. The article explains how. “Microarchitectural Data Sampling (MDS) is a group of vulnerabilities that allow an attacker to potentially read sensitive data.” That is way more serious than stealing cycles.

Ye, but I didn't understand how this was different than Spectre, except with different caches. Still it's fine with no JS and no shared processor time, right?

Right. If you run no foreign code you are safe.
Post reply on HN