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

81–90 of 118 posts

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

#81

Post by Twirrim »

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…

As with Spectre/Meltdown, L1TF et al, Intel chooses who to loop in to their disclosure.

All of it is tightly controlled under an embargo. Who they choose to involve is entirely their decision, and is likely based on previous experience with those parties and their likelihood of leaking. Intel doesn't want these kinds of things to leak before official communication is done, or it's pretty much guaranteed to impact their stock price.

This time around has gone much smoother than the previous ones, though L1TF was pretty good too. L1TF was a little rough with the patching side of things because the patches were finalised a little late.

The various distributions and companies knew that the embargo was due to end at 10am pacific, and were probably (like us) refreshing the security advisories page on Intel's site waiting to pull the trigger on all the relevant processes, like publishing blog pages etc.

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

#82

Post by Twirrim »

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's other people working on it outside of Intel, too. https://mdsattacks.com/ if you look at the list of people you'll see there's dozens of folk that independently found and reported the same vulnerabilities.

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

#83

Post by Twirrim »

consp wrote: post #78
temac wrote: post #51

Earlier quoted context omitted.

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.

Right, and it takes time to build and comprehensively test a fix.

Anything on the CPU level that needs to be done in microcode is incredibly complex, and hard to test.

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

#84

Post by kccqzy »

api wrote: post #73
kccqzy wrote: post #69

Earlier quoted context omitted.

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.

I still don't think so. Exposing these microarchitectural concerns to the architectural level limits flexibility. In order for compilers to efficiently schedule multiple execution units, the compiler needs to know the exact latency of all instructions. That may be doable for arithmetic, but varies greatly from one generation of processor to the next. And compilers definitely cannot know the latency of a load: from a few cycles in L1 cache, to a few thousand cycles in DRAM, to millions of cycles if there's a page fault. And these things vary a lot, not just between processor generations but within the same processor generation.

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

#86

Post by neop1x »

Wowfunhappy wrote: post #25
Causality1 wrote: post #4

For me as a home user, taking a performance hit of any kind in response to threats which haven't yet been seen in the wild simply isn't good math.

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.

Your public clouds at AWS probably use them too... and they won't disable HT ;)

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

#87

Post by fakwandi_priv »

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 relevant cases of interest: process-to-process, kernel-to-userspace, guest-to-guest, and SGX-enclave-touserspace leaks. Not to mention that such attacks can be built even from a sandboxed environment such as JavaScript in the browser, where the attacker has limited capabilities compared to a native environment.

[0] https://mdsattacks.com/files/ridl.pdf

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

#88

Post by snovv_crash »

rightbyte wrote: post #56
silversconfused wrote: post #26

Earlier quoted context omitted.

One CPU per process makes a lot more sense, especially now that we have so many specialized CPUs in our machines anyway.

Ye I got a feeling that shared processor time with strangers is not viable without specialized hardware.

I think it isn't viable with non-deterministic (in time) hardware behavior. This means dedicated caches, or no caches at all. Dedicated guaranteed memory speeds and latencies. Dedicated processing units. The untrusted code cannot be affected by other code, otherwise the other code leaks its usage patterns across.

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

#89

Post by beagle3 »

pertymcpert wrote: post #79
beagle3 wrote: post #18

Earlier quoted context omitted.

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?

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

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

#90

Post by [deleted] »

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…

[deleted]
Post reply on HN