Talk:Microarchitectural Data Sampling

Lead

The phasing of the lead section is confusing and the grammar could be improved. What does "...whilst those data are not architecturally supposed to be visible across" actually mean? 83.104.249.240 (talk) 09:30, 15 May 2019 (UTC)

Assume it was supposed to read "which". —DIYeditor (talk) 11:34, 15 May 2019 (UTC)

2011

What is the significance of 2011? What was the architecture change that introduced the flaw? 83.104.249.240 (talk) 09:34, 15 May 2019 (UTC)

Wired article say chips going back to 2008? —DIYeditor (talk) 16:21, 15 May 2019 (UTC)

Any notable attacks using the exploits yet?

Probably unlikely, but if there was a notable attack using any of the exploits we should probably mention it in the article. Kirbanzo ^{(userpage - talk - contribs)} 14:51, 15 May 2019 (UTC)

Favoritism towards ZombieLoad

I noticed at the time of this writing, almost every time the three exploits are mentioned, ZombieLoad appears first and I do not see why this should be. Alphabetically, ‘Z’ should be last, and even if when going by CVE numbers, RIDL (CVE-2018-12127) seems to have came before ZombieLoad (CVE-2018-12130 which may actually be part of RIDL). Should we be listing these alphabetically or otherwise?

Even the Wikipedia article is linking the official website as zombieloadattack.com. Why not mdsattacks.com?

After all, while news on the internet seems to skew in either direction -- some mentioning only RIDL & Fallout , others mentioning ZombieLoad, and some mentioning all three -- RIDL and Fallout has the earliest (and the most) CVE numbers, AMD and RedHat seem to only recognize RIDL and Fallout, and according to Wired only Amsterdam’s VUSec received Intel's $100,000 bounty, apparently for RIDL. Sadly this seems only hinted in the history of the article.

I'm guessing that only those from the ZombieLoad side were the ones that worked on this page so far, while nobody familiar with RIDL and Fallout stepped up to contribute. This would explain zombieloadattack.com being a top-level source (currently #3) while nothing from mdsattacks.com appears in the article.

If this is the case, I would be happy to follow up with the RIDL and Fallout groups to see if they are willing to help contribute. I am sure a cohesive story can be told that brings in the history of all three exploits instead of focusing on one.--Ianozia (talk) 23:22, 15 May 2019 (UTC)

Mitgatable?

Is this really mitigatable via a kernel update?

Linux 5.1.5, for example still reports vulnerable (within a VM) :

[root@testbox /] # uname -a
Linux testbox 5.1.5 #1 SMP Mon May 27 10:21:56 EST 2019 x86_64 GNU/Linux
[root@testbox /] # cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown

False claim about microcode updates requiring MB firmware updates.

"Microcode is the implementation of processor instructions on the processor itself, and updates require a firmware patch,[1] also known as BIOS or UEFI, to the motherboard." This is patently false. Operating systems such as any reasonably modern Linux distributions and Windows versions can and do upload microcodes fixes to the CPU during the boot process. Unfortunately I don't know a citable source for this. So maybe if you know one? -- 10:07, 30 August 2019 (UTC) — Preceding unsigned comment added by 194.39.218.10 (talk)