Talk:Transient execution CPU vulnerability

SpectreRSB

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)[reply]

Looks like this vulnerability affected only the Linux kernel and has long been fixed. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15572 Probably we may remove it from the table. Artem S. Tashkinov (talk) 14:06, 8 August 2019 (UTC)[reply]

15572 is a Linux kernel issue, but there is also a distinct RSB subvariant of Spectre variant 2, which is the CPU-level issue. That's the distinction I'm getting at. Ewx (talk) 20:46, 10 August 2019 (UTC)[reply]

New RIDL Variants

https://mdsattacks.com/files/ridl-addendum.pdf variant B

RIDL but for transactional memory aborts
CVE-2019-11135
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00270.html

https://mdsattacks.com/files/ridl-addendum.pdf variant C

RIDL but for alignment fauls
Couldn't find a CVE
Couldn't find an Intel response

Ewx (talk) 12:01, 13 November 2019 (UTC)[reply]

CVE-2019-11135 is already in the table under ZombieLoad v2 Artem S. Tashkinov (talk) 13:30, 13 November 2019 (UTC)[reply]

Oh, sorry! Ewx (talk) 22:49, 13 November 2019 (UTC)[reply]

Oversimplified Table

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)[reply]

I'm utterly confused. The article is not written in any way - I just listed vulnerabilities in the table in the order they've been found. I also don't list research teams or attiribution or anything like that - just CVEs and vulnerabilities names/monkiers. If you want to rework the table and include all this information which I doubt is necessary or even pertinent (since this article is about vulnerabilities, not researches or research which probably should go to appropriate Wikipedia articles) then go ahead and do what you want. It's just a table for quick reference. Artem S. Tashkinov (talk) 19:54, 2 January 2020 (UTC)[reply]

Except the table seems to refer to MFBDS as ZombieLoad and TAA as ZombieLoad V2, which are brand names used by only one of the teams, whereas the other research teams either refer to the issue as RIDL (MFBDS/MLPDS/MDSUM/TAA) or Fallout (MSBDS) or the more neutral MDS/TAA (Intel naming). Leaving out one of the brand names does make the article look more like it favours one over the other, so it makes sense to mention both names, especially since RIDL seems to cover MFBDS/TAA as well (as evidenced by the acknowledgements). Adinterix (talk) 20:41, 2 January 2020 (UTC)[reply]

I've tried my best to list all existing names and I didn't even think of them as "brand names". The researchers behind these teams made up those names mostly for fun and I've never seen a trademark filed for any of these vulnerabilities. Anyways I'm OK with your edits. Artem S. Tashkinov (talk) 02:14, 3 January 2020 (UTC)[reply]

Zombieload should be removed as a duplicate in favor of RIDL

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.
— Intel's Security Advisory 00270

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)[reply]

Guys, if you feel like you're a lot more knowledgeable in the matter then go ahead and change the article the way you feel it should be. I've just followed the news and added new vulnerabilities without trying to be precise or encyclopedic in their classification. It's hard to be encyclopedic when the whole issue is extremely complicated ^[1]. Artem S. Tashkinov (talk) 19:58, 2 January 2020 (UTC)[reply]

References

^ https://transient.fail/

Singular

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)[reply]

Agreed. User:The_Anome could you engage here rather than changing the page without explanation? Ewx (talk) 19:42, 18 March 2020 (UTC)[reply]

@Artem S. Tashkinov and Ewx: Please see Wikipedia:Naming conventions (plurals). -- The Anome (talk) 17:34, 20 March 2020 (UTC)[reply]

Thankyou. Putting that in the original change message would have saved a lot of time. Ewx (talk) 18:13, 20 March 2020 (UTC)[reply]

Spectre v1 mitigations Intel v. AMD

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)[reply]

I don't get it either! And if Zen 2 has hardware mitigations, are those complete enough to mark it as not-affected? Indolering (talk) 01:59, 11 June 2020 (UTC)[reply]

Table Coloring

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)[reply]

Zen 3 vulnerability

kindly update the table and add zen 3 data https://www.tomshardware.com/news/amd-zen-3-cpu-susceptible-spectre-like-vulnerability

I'm not sure it's worth adding for the following reasons. 1) It was implemented only by AMD and only in Zen 3 2) According to Phoronix [1] the performance impact is near zero. Artem S. Tashkinov (talk) 16:16, 5 April 2021 (UTC)[reply]

Meltdown-like Vulnerability Affects AMD Zen+ and Zen2 Processors

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)[reply]

Focus on AMD

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)[reply]

[1] ttps://transient.fail/

[1]