
MDS: Microarchitectural Data Sampling side-channel vulnerabilities in Intel CPUs - sirmc
https://mdsattacks.com
======
JdeBP
Commentary by Intel: [https://software.intel.com/security-software-
guidance/softwa...](https://software.intel.com/security-software-
guidance/software-guidance/microarchitectural-data-sampling)

Commentary by RedHat: [https://www.redhat.com/en/blog/understanding-mds-
vulnerabili...](https://www.redhat.com/en/blog/understanding-mds-
vulnerability-what-it-why-it-works-and-how-mitigate-it)
([https://news.ycombinator.com/item?id=19912108](https://news.ycombinator.com/item?id=19912108))

Commentary by Ubuntu: [https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-
mitigat...](https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-
microarchitectural-data-sampling-mds-vulnerabilities)

~~~
tarlinian
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...](https://software.intel.com/security-software-
guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling)

Details of which steppings of which processors are affected by which CVEs:
[https://software.intel.com/security-software-
guidance/insigh...](https://software.intel.com/security-software-
guidance/insights/deep-dive-cpuid-enumeration-and-architectural-msrs#MDS-
CPUID)

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

------
titzer
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](https://www.chromium.org/Home/chromium-security/mds)

~~~
wyldfire
> 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 does everyone know what policies that the constituent
companies use to prevent early disclosure or unintended disclosure to
'somewhat-less-trusted-employees'? Is this all coordinated by US CERT?

[1] [https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-
mitigat...](https://blog.ubuntu.com/2019/05/14/ubuntu-updates-to-mitigate-new-
microarchitectural-data-sampling-mds-vulnerabilities)

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

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

~~~
beagle3
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 off (using 2 core / 2
threads) than with HT on (using 2 core / 4 threads) - there just wasn't enough
cache to support those many threads.

~~~
pertymcpert
What do you think is a good performance improvement then?

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

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

~~~
beagle3
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?

~~~
pertymcpert
No there isn’t. But if you understand it I don’t get why you think 20% isn’t a
good performance boost, especially considering the rate of return for power
and area in silicon.

~~~
beagle3
Because many people believe it is a 100% improvement, plan/budget accordingly,
and then look for help.

As far as silicon/power it is nice, but IIRC (I am not involved in purchasing
anymore) it used to cost over 50% in USD for those 20% in performance when you
non-HT parts were common.

~~~
pertymcpert
What a strange way to measure the benefits of a performance optimization: "how
people will perceive it and then ask me for help".

~~~
beagle3
You ignored the price issue, which was measurable and real, but also:

It (used to be) my job. Does "because people fall for deceptive marketing,
waste money, and then waste my time trying to salvage their reputation" sound
better?

------
thro_away_n
Am I reading correctly that this has been under embargo for over a year?

~~~
kmfrk
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](https://mdsattacks.com).

~~~
temac
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 independently by
tons of teams. Expecting that well-financed actors have _not_ explored that
field and/or _not_ yield any similar result at this point is completely
insane.

Meaning, given the high level of technicality required, it's even doubtful
that the embargo protected anybody; it might be that no attacker exist (and I
postulate will ever exist) that will be simply waiting for 3rd party
disclosure before writing its own exploits in that class. On the other hand,
typical security providers monitoring threats in the field might not be aware
for a long time of the existence of such vulnerabilities.

Now here arguably the first counter measures are similar to those for L1TF, so
hopefully sensitive operators would already have disabled HT. However, it is
not very cool to not make them aware of this additional (and slightly
different) risk during such a ridiculously long period.

Also: does Intel has competent people working on their shit anymore??? They
know the fundamental principles; which is speculative execution on
architecturally out-of-reach data, followed by a fault and a subsequent
extraction via covert channels of un-rolled-back modified micro-architectural
state. The broad micro arch is widely known, so do they _really_ expect that
3rd party security researchers won't found all the places where they were
sloppy enough to speculatively execute some code on completely "garbage" data?
Or were they themselves unable to do a proper comprehensive review, despite
having access to the full detailed design (and despite a dedicated team having
been created for that)? In either case, this is not reassuring.

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

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

------
Rafuino
Better Intel page on the MDS vulnerability is here:
[https://www.intel.com/content/www/us/en/architecture-and-
tec...](https://www.intel.com/content/www/us/en/architecture-and-
technology/engineering-new-protections-into-hardware.html).

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.

~~~
fakwandi_priv
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](https://mdsattacks.com/files/ridl.pdf)

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

~~~
annoyed_lurker
Page 16 in the slides[1] lists vulnerable processors, 8700K is one of them

[1]
[https://mdsattacks.com/slides/slides.html](https://mdsattacks.com/slides/slides.html)

edit: This is mentioned in the paper as well, on page 8

------
thijser
In a Dutch article ([https://nos.nl/artikel/2284630-nederlanders-vinden-
beveiligi...](https://nos.nl/artikel/2284630-nederlanders-vinden-
beveiligingslekken-in-intel-chips.html)), 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 there surely
are bigger teams working on this kind of stuff?

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

~~~
ghettoimp
Out of curiosity, where would the others be?

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

------
JdeBP
The overview page, [https://cpu.fail/](https://cpu.fail/) , is on Hacker News
as
[https://news.ycombinator.com/item?id=19911715](https://news.ycombinator.com/item?id=19911715)
.

~~~
Thorrez
What does "UC" in "Meltdown UC" mean?

~~~
orhmeh09
Microcode most likely.

------
mehrdadn
Also for MDS: [https://www.intel.com/content/www/us/en/security-
center/advi...](https://www.intel.com/content/www/us/en/security-
center/advisory/intel-sa-00233.html)

I like how Intel prominently thanks their own employees for finding the bugs
and later simply acknowledges the existence of any anyone independent
reporters with zero thanks.

~~~
BorRagnarok
Interesting. This could mean that Intel actually discovered and thus knew
about all those security-holes before the non-Intel researchers did.

Or they're just being awkwardly disingenuous here, that's also a possibility.

------
bigato
funny that you don't see their email address for contact if you don't have
javascript running, which is exactly one of the doors for this kind of
vulnerability as they mention on their site

------
dexen
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, Konqueror (of KDE) had reasonably fast bytecode JS engine. I wish the
browser was still undergoing fast development, used to be my daily driver for
many years.

~~~
sigotirandolas
AFAIK, there are techniques to detect and denoisify minuscule timing
differences over millions of samples, and the fundamentals of most techniques
apply to interpreters as well, so it is not a solid protection.

That said, it would make things harder in practice since you’re introducing an
extra indirection level and just making everything slower.

As for interpreters in modern browsers, I’d be surprised if there’s no way to
entirely disable the JIT somehow... since most JIT implementations I have seen
have an interpreter fallback for debugging and easier portability to new CPU
architectures.

------
classic959
The interactive guide on that page is an effective way to visualise the
components in relation to the attacks.

Does anyone know what this would have been built with?

------
josh2600
Am I reading this right? It looks like this bug lets you read any part of an
intel chip's processing payload in-flight?

That's gnarly if true.

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

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

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

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

------
outworlder
Again, Intel CPUs only.

~~~
neop1x
Can I ask for money back? Intel should return 30% cost of all vulnerable CPUs
then... because disabling HT is effectively reducing the claimed performance
specs.

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

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

~~~
PureParadigm
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...](https://yux.im/posts/technology/security/disable-meltdown-and-spectre-
patches-on-linux/)

~~~
iddqd
Here is a similar windows tool:
[https://www.grc.com/inspectre.htm](https://www.grc.com/inspectre.htm)

------
Theodores
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 hide there. Meanwhile, people doing important work on
proper computers are properly vulnerable to this new Hyperthreading
theoretical attack.

I will be interested to find out if there is a drop-off in performance on
ChromeOS, e.g. Youtube stuttering whilst the whatsapp web tab updates itself
with a new message. If there is nobody complaining then why did we need Hyper-
Threading in the first place?

~~~
silversconfused
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 able to start taking market share
back. Nothing interesting happens between then and threadripper, but now we
would be back to eating popcorn and watching the rest of the fight..... but
the fight is over and everyone is over in the other arena watching arm and
webkit winner-take-all style demolishing the incumbent platforms.

~~~
DeepYogurt
> 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/Hyper-threading)

[https://en.wikipedia.org/wiki/Athlon_64](https://en.wikipedia.org/wiki/Athlon_64)

