Talk:Transient execution CPU vulnerability

Computing: Software / Security Mid‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles

Mid

This article has been rated as Mid-importance on the project's importance scale.

This article is supported by WikiProject Software (assessed as Low-importance).

This article is supported by Computer hardware task force (assessed as Mid-importance).

This article is supported by WikiProject Computer Security (assessed as High-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

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]

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

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

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

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

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

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

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

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

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

Rendering behavior may vary across operating systems, themes, installed fonts, and whatnot, so even if it looks good for one person on both browsers, that doesn't mean it isn't broken for some people. The old markup is still broken for me when I look at it with Firefox 126.0-7 on Fedora Linux. I scrubbed the CSS floats and absolute positioning directives that were causing overlapping text. In general, simpler markup is better because it's more likely to work across lots of different platforms, even if it's not as beautiful on one specific platform. We don't have the resources to test complicated markup across all the mobile and desktop browsers and operating systems that people use to read articles, not to mention the print and audio-only versions. -- Beland (talk) 21:37, 24 May 2024 (UTC)[reply]

Why isn’t this called “Speculative execution CPU vulnerabilities”?

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

Not all of them are "speculative". Artem S. Tashkinov (talk) 11:17, 3 June 2024 (UTC)[reply]

The “overview” section of this very article defines transient execution vulnerabilities in terms of speculative execution.
So does Intel’s definition which I linked to.
Name one that isn’t?

Kr5t (talk) 15:44, 11 June 2024 (UTC)[reply]

Survey of Transient Execution Attacks and Their Mitigations cited by 54.

Lots more.

It's an established term used among the security researchers and your OEM links include just selected speculative execution vulnerabilities. If you want to create a new article with just "speculative execution vulnerabilities", I have no issues with that. This article encompasses a lot more. Artem S. Tashkinov (talk) 11:23, 3 June 2024 (UTC)[reply]

Of course it’s an established term, I acknowledged that in my first sentence. But “speculative execution attack” is more established than “transient execution attack” (which is much more widely used than “transient execution vulnerability”, as can be seen from your own links, and in this context they’re not meaningfully different), eg the Spectre paper got 2,912 citations of course, but if we’re talking random papers, this got 146, nearly 3x as many as your 54-cite paper. I personally think chipmakers’ own terminology is more relevant than citation counts of random papers, but it leads to the same conclusion. Kr5t (talk) 16:02, 11 June 2024 (UTC)[reply]

[1] ttps://transient.fail/

[1]