MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs • Hacker News Board

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

#41

Post by tarlinian » Tue, May 14, 2019, 6:54 PM UTC

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

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

#42

Post by jcelerier » Tue, May 14, 2019, 6:55 PM UTC

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 music production and C++ code compilation I get a pretty reliable +25% perf boost with HT on (this was not the case a few gens ago though).

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

#43

Post by Rafuino » Tue, May 14, 2019, 6:56 PM UTC

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.

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

#44

Post by Causality1 » Tue, May 14, 2019, 6:57 PM UTC

jMyles wrote: post #34

Causality1 wrote: post #20

Earlier quoted context omitted.

Everything that can't be fixed with a ten minute phone call to my bank is already public knowledge thanks to Experian, so I really don't have anything left to fear.

You have no conversations that'd you prefer not be sold on the darknet? With friends, family, therapists, doctors, lawyers, consultants? No pictures of your kids that they might not want spilled into a searchable database and used for machine learning to sell them things later in life? No private or symmetric keys which might be used to impersonate you or eavesdrop on you later? No in-progress documents which you are…

Not on any x86 device, no. Not that I'd be a particularly easy target since I use NoScript with a whitelist and keep my router's firewall very strict. I suppose someone could come at me with a malicious Steam game.

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

#45

Post by penagwin » Tue, May 14, 2019, 7:04 PM UTC

silversconfused wrote: post #24

smnra wrote: post #13

Earlier quoted context omitted.

30% performance hit? I'm sure that heavily depends on the workload... and I'm also sure you lose performance when HT is on, depending on the workload as well.

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.

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

#46

Post by [deleted] » Tue, May 14, 2019, 7:05 PM UTC

orhmeh09 wrote: post #37

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 you use Steam, it’s in the best interests of you and probably Valve not to worry about attacks to steal your library or get you banned.

[deleted]

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

#47

Post by baq » Tue, May 14, 2019, 7:07 PM UTC

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.

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

#48

Post by dang » Tue, May 14, 2019, 7:08 PM UTC

sctb wrote: post #31

JdeBP wrote: post #6

The overview page, https://cpu.fail/ , is on Hacker News as https://news.ycombinator.com/item?id=19911715 .

Thanks! We've merged these.

And unmerged them. See https://news.ycombinator.com/item?id=19912588.

Sorry for the chaos but this was a weird edge case. The marketing maybe went overboard this time?

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

#49

Post by Causality1 » Tue, May 14, 2019, 7:09 PM UTC

fwsgonzo wrote: post #36

Causality1 wrote: post #20

Earlier quoted context omitted.

Everything that can't be fixed with a ten minute phone call to my bank is already public knowledge thanks to Experian, so I really don't have anything left to fear.

"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -E. Snowden

Did you miss the "for me" part? I highly encourage everyone to install the patch, especially since the more people do the less I'll need it.

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

#50

Post by olliej » Tue, May 14, 2019, 7:10 PM UTC

dexen wrote: post #40

End-user security, in web browser context: do I understand it correctly that if my browser was to only ever execute JavaScipt in bytecode format (without compilation to native code) it would be safe from those kinds of exploits? Presuming the bytecode interpreter would be "slow enough" and "jittery enough" and "indirect enough" to hamper any attempts at exploiting subtle timing+memory layout bugs like that? IIRC, Kon…

[edit: I finally finished reading everything. It seems like these new leaks can be triggered from JS as they still fundamentally reduce to "read time for memory access"]

For spectre simply having attacker directed control flow was sufficient - so logically almost any scripting language could be exploited.

Same goes for most of the TLB attacks.

Others required native code because they needed to use specific instructions (that aren’t going to be emitted intentionally by any compiler - jit or otherwise).