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)

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)

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)

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)

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

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

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)

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)

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)

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)

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)

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 . Artem S. Tashkinov (talk) 19:58, 2 January 2020 (UTC)

References

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)

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

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

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

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)

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)

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)

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)

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)

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)

I don't really agree that it implies that (since Arm and Intel issues are also mentioned), but the section does need some work. The top half is a reasonable overview but the bottom half has degenerated into an incomplete timeline. My suggestion would be that the bottom half be reworked into a new section covering specific issues, where those issues benefit from more detail than a row in a table but don't have a page to themselves (whether because they don't justify it or because nobody has created one)

TBH I think your criticism would be truer of the table, which focusses only on x86 issues, ignoring other architectures. It might be better to have one or more extra tables for other architectures, to avoid it getting unwieldy. Ewx (talk) 19:20, 7 February 2022 (UTC)

Future section

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)

Migrate table information to Wikidata

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)

Affected CPU architectures and mitigations

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)

Intel's and AMD's are the primary architectures. A note with other affected architectures may be added to specific vulnerabilities by those willing to investigate about them. =)) Or probably better a new table below with Vulnerabilities \ Architecture families affected.

Regarding newer architectures, there's no sense to include them for vulnerabilities before the BHI because there are no changes going further: they're either already (partially) fixed in hardware / not affected or the fix is software-only and the same for all affected CPUs. A note about this could be added similar to 8th gen.
For vulnerabilities after the BHI there are 2 options:

• extend the existing table with architectures causing a switch in mitigation type. But the problem is that in current default Wikipedia skin there's no horizontal space left (in fixed-width layout) and the scrollbar will appear. Moreover, there's no sense to include them for vulnerabilities before the BHI;
• add a new table below just for those vulnerabilities and newer architectures with a switch in mitigation type (like Intel did with its table).

EvgenKo423 (talk) 14:29, 2 May 2024 (UTC); updated 06:57, 3 May 2024 (UTC)

Broken formatting

@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)

What's broken for you exactly? It looks OK in Chrome 108. If you mean that second CVE doesn't have a year (it's the same), then that's intentional to not bloat the row height in fixed-width layout. Other than that I don't think I'll be able to fix what's on your end.
EvgenKo423 (talk) 12:54, 2 May 2024 (UTC); updated 06:57, 3 May 2024 (UTC)

@EvgenKo423

Here take a look: https://ibb.co/Vj57zW1 That's Firefox 123.0.3

In Chrome it's not too much better: https://ibb.co/N9zv2QB Artem S. Tashkinov (talk) 11:16, 3 May 2024 (UTC)

Still looks OK for me in fresh Firefox 125.0.3 (latest): https://ibb.co/pPwZKRL. And Chrome is what I call intentional.
Try private mode or resetting your browser. EvgenKo423 (talk) 06:49, 4 May 2024 (UTC)