![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
Some sources regard this as a separate variant - some seem to classify it as a subvariant of Spectre Variant 2. https://nvd.nist.gov/vuln/detail/CVE-2018-15572 only really covers a gap in the Linux kernel mitigations on x86, rather than the issue as a whole. In a forthcoming edit I'll try to reflect this more accurately but other angles welcome. Ewx ( talk) 08:30, 6 August 2019 (UTC)
https://mdsattacks.com/files/ridl-addendum.pdf variant B
https://mdsattacks.com/files/ridl-addendum.pdf variant C
Ewx ( talk) 12:01, 13 November 2019 (UTC)
It is clear that ZombieLoad and RIDL are found by two independent research groups that have no overlap, however, the article is currently written in a way that MFBDS and TAA are only attributed to ZombieLoad and ZombieLoad V2, which is unfair to the research group who found RIDL.
RedHat Access seems to provide CVE information and acknowledgements for CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 and CVE-2019-11091. Furthermore, these acknowledgements seem to be in chronological order, which means that the RIDL team found MFBDS before the ZombieLoad team, and that the ZombieLoad team found MDSUM before the RIDL team (which is weird given that MDSUM has a 2019 CVE).
In addition, Intel's Security Advisory 00233 seems to also provide a chronological order for the acknowledgements, again acknowledging the RIDL team for MFBDS.
Finally, Intel's Security Advisory 00270 not only acknowledges the RIDL team for TAA, but also mentions that the RIDL team discovered and reported this in September 2018 [!] whereas the ZombieLoad team discovered and reported this in April 2019.
Unfortunately, the table in the article does not represent this information at all, and instead only attributes MFBDS and TAA to ZombieLoad. Given the fact that the RIDL team discovered and reported both MFBDS and TAA before the ZombieLoad team, it would be appropriate to at the very least mention MFBDS and TAA for RIDL as well, especially since the RIDL paper mentions CVE-2018-12130 (MFBDS) and as it seems to mostly focus on Fill Buffers (again MFBDS) as well.
Adinterix ( talk) 11:09, 2 January 2020 (UTC)
I noticed that the revision "Provide correct CVEs plus references to the acknowledgments for RIDL" was undone with notes "Everything was already here in the table. No need for duplicates". In favor of having no duplicates, I recommend that we remove ZombieLoad altogether for CVE-2018-12130 and CVE-2019-11135 from this index. Chronologically speaking, RIDL team found both vulnerabilities first.
First, as Adinterix has mentioned, RedHat seems to credit VU Amsterdam before TU Graz -- in a list that is in chronological order -- for CVE-2018-12130.
Furthermore, as RIDL has been credited on Microarchitectural Data Sampling for CVE-2018-12127, CVE-2019-11091 and CVE-2018-12130 and ZombieLoad has been credited only for CVE-2018-12130, would it be feasible to classify CVE-2018-12130 as part of RIDL instead of ZombieLoad? VUSec group at VU Amsterdam appears to be the only group publicly known to receive a bounty -- of $100,000 according to Wired -- for the group of CVEs attributed to RIDL.
As for CVE-2019-11135, Intel specifically states:
Researchers from VUSec group at VU Amsterdam and CISPA Helmholtz Center provided Intel with a Proof of Concept (POC) in September 2018 and researchers from TU Graz and Ku Leuven provided Proof of Concept (POC) in April 2019.
This should be enough evidence that VU Amsterdam discovered CVE-2019-11135 before TU Graz.
If we are delisting duplicates, we should replace "ZombieLoad v2" with "RIDL" for CVE-2019-11135, and probably replace "ZombieLoad" with RIDL for CVE-2018-12130, as VU Amsterdam seems to have been credited with discovering these vulnerabilities first in addition to being the only group to net a bounty from Intel for them.
If we're going to have duplicates, RIDL should be credited for both CVE-2018-12130 and CVE-2019-11135 for the above reasons mentioned.
Ianozia ( talk) 15:54, 2 January 2020 (UTC)
References
Why? It makes zero sense to me, it hasn't been discussed, or voted on. I really really dislike this change/edit. I'm inclined to revert this edit if we don't get the rationale. Artem S. Tashkinov ( talk) 13:43, 12 March 2020 (UTC)
Indolering I'm am an absolute no one in this issue/field but I'm curious how come Intel needs software recompilation while AMD is just fine with "Hardware + OS/VMM". This doesn't seem right. Artem S. Tashkinov ( talk) 08:37, 9 June 2020 (UTC)
It would be ideal if the table colored mitigations according to the effectiveness of the mitigation / severity of the attack on the platform. There is "not patched", software recompilation, OS/VMM, Microcode, hardware, and 'not affected." I'm unsure of how to handle the color formatting and I don't understand the mitigation effectiveness for each bug, please feel free to jump in and make suggestions. Indolering ( talk) 02:49, 11 June 2020 (UTC)
kindly update the table and add zen 3 data https://www.tomshardware.com/news/amd-zen-3-cpu-susceptible-spectre-like-vulnerability
need to add this https://www.techpowerup.com/286119/meltdown-like-vulnerability-affects-amd-zen-and-zen2-processors
Cybersecurity researchers Saidgani Musaev and Christof Fetzer with the Dresden Technology University discovered a novel method of forcing illegal data-flow between microarchitectural elements on AMD processors based on the "Zen+" and "Zen 2" microarchitectures, titled "Transient Execution of Non-canonical Accesses." The method was discovered in October 2020, but the researchers followed responsible-disclosure norms, giving AMD time to address the vulnerability and develop a mitigation. The vulnerability is chronicled under CVE-2020-12965 and AMD Security Bulletin ID "AMD-SB-1010."
223.177.40.79 (
talk)
05:29, 30 August 2021 (UTC)
The Overview part makes this look like this is a mostly AMD-only problem, because Intel does not get any concrete coverage; this perception would be quite wrong. Only the table shows the actual situation. -- 109.193.56.97 ( talk) 01:00, 6 February 2022 (UTC)
The statement that Spectre variants will never be fixed in hardware due to unavoidable performance loss may turn out to be true but it certainly needs a citation, if it's going to appear in a Wikipedia article. I've tagged it for now and will delete it if no citation appears in due course. Ewx ( talk) 10:58, 27 June 2022 (UTC)
Presently, there is no information about vulnerabilities and possible vulnerabilities on each microarchitecture's page. Manually updating each page is an error prone process that can easily go out of date due to the information being so dispersed. The ideal solution seems to be moving vulnerability information to Wikidata. This way, the information could be displayed both in a brief per processor as well as a large collective table of data, like the one on this page. GravisZro ( talk) 13:01, 22 July 2022 (UTC)
This part of the table should be dropped and replaced with the list of vendors and architectures, instead of giving an overview of only Intel/AMD architectures whose number will be growing on and on. When the article was devised I hoped very distant new yet to be released uArchs wouldn't be affected but I've been proven wrong. Even now this part of the table is already incomplete as it doesn't include AMD's Zen 3 and Zen 4 uArchs and Intel's TGL, ADL and RPL (though RPL doesn't seem to be any different than ADL). Artem S. Tashkinov ( talk) 21:36, 16 September 2023 (UTC)
@ EvgenKo423 The lists of CVEs under Branch History Injection (BHI) and Retbleed look broken on my end. Could you please fix it? Artem S. Tashkinov ( talk) 07:48, 2 May 2024 (UTC)
TL;DR “transient execution” is used by a minority of papers and industry parties; it should be an “also known as”, and the title should use “speculative execution”
The original Meltdown and Spectre papers explicitly define the term “transient instructions” in terms of speculative execution (you wouldn’t want to call them speculative instructions because the instructions themselves, of course, are very real, they just shouldn’t have been executed); the Meltdown paper never uses the term “transient execution”, and the Spectre paper uses it just once in passing (transiently, one might say) without defining it, in a way that was synonymous with speculative execution. https://meltdownattack.com/
As far as I can tell, the term “transient execution attack” was coined by the Foreshadow paper; when it introduces the term, it has 5 citations, none of which ever use the term. https://foreshadowattack.eu/
(Other important early papers: RIDL aka MDS never even uses the word transient, but Fallout and ZombieLoad use the term “transient-execution” (hyphenated) extensively.)
AMD, ARM, Apple, Microsoft, and Cloudflare’s general guidance on this class of attacks does not use “transient” at all:
(Some of their articles on specific attacks do use the term, especially if the attack’s own white paper uses it.)
Intel appears to be the only industry party that consistently uses the term “transient execution attack”, and even states a specific definition. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html
Overall, just calling them speculative execution vulnerabilities is much more established than this term “transient execution” that appears in no other context. Kr5t ( talk) 19:10, 1 June 2024 (UTC)