Talk:Meltdown (security vulnerability)

Merge request

Please merge this article with Kernel page-table isolation. -Mardus /talk 22:18, 3 January 2018 (UTC)

Ideally this page would be about the Meltdown vulnterability, and KPTI would just be about the mitigation/feature? Though I'm not sure how different they both are. Legoktm (talk) 23:46, 3 January 2018 (UTC)

KPTI/KAISER was originally proposed primarily as an extremely broad (but potentially costly!) mitigation for KASLR bypass attacks. I believe it was proposed before Meltdown was discovered. Meltdown is much worse than a simple KASLR bypass, being able to outright read all mapped memory. KPTI/KAISER, being a very broad hammer, happens to stop the reading of kernel memory using the bug, and that is why it was actually adopted. 184.176.111.201 (talk) 00:33, 4 January 2018 (UTC)

Where's Spectre

I don't see an article about Spectre (security bug) Artem-S-Tashkinov (talk) 23:59, 3 January 2018 (UTC)

 Done - please see the newly created article at => Spectre (security bug) - help in developing the article is welcome - in any case - Enjoy! :) Drbogdan (talk)

While we are at it, I fail to see an article about BlueBorne - how come no one has written it yet? The Russian and Japanese wikipedias feature it, the English has just a small reference in the BlueTooth article. Artem-S-Tashkinov (talk) 16:27, 4 January 2018 (UTC)

 Done - @Artem-S-Tashkinov: (and others) - for starters - please see the newly created article at => BlueBorne (security vulnerability) - help in developing the article is welcome - in any case - Enjoy! :) Drbogdan (talk) 14:51, 5 January 2018 (UTC)

Requested move 4 January 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Already moved by Legoktm. Anarchyte (work | talk) 05:39, 4 January 2018 (UTC)

---

• Meltdown (security bug) → Meltdown (security vulnerability)
• Spectre (security bug) → Spectre (security vulnerability)

The article security bug explicitly defines that as software, as does the article vulnerability (computing). It is not clear that these are single bugs (unlike say the FDIV bug) but rather a pattern of weakness in the implementations of out-of-order execution and speculative execution. For consistency both of these articles should be named in the same manner and be congruous with the definitions used in existing articles. —DIYeditor (talk) 00:58, 4 January 2018 (UTC)

Makes sense,  Done Legoktm (talk)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Possible merge with Spectre (security vulnerability)?

Both of these bugs were discovered at the same time and almost all news articles I've come across have been talking about both of them simultaneously and almost interchangeably (in some cases). If this were to be merged, we could rename the article to Meltdown and Spectre security vulnerabilities. Pinging article creators: @Drbogdan and Legoktm:. Anarchyte (work | talk) 05:43, 4 January 2018 (UTC)

My understanding is these two bugs are going to have different impacts. It seems like Meltdown has patches available and will mostly be mitigated. It also mostly affected cloud providers. But Spectre is a whole different story, it affects all chip manufacturers and all types of devices. The paper mentions that they were able to execute JavaScript in Google Chrome and read into private memory straight from there. And it looks like the general mitigation strategy is to cripple browser features ([1]) and wait for a fix in hardware, which will take years. I haven't had time to finish reading the Spectre paper yet so please correct me if I'm wrong. Legoktm (talk) 06:28, 4 January 2018 (UTC)

The impacts are going to be different, but the source of the two vulnerabilities is the same. They were even announced at the same time and share a site. Furthermore, from a certain perspective Meltdown can be thought of as as a special case of the more general Spectre one. Thus, I'd at least support a merge.

At the same time I'd say the specific mitigations clearly deserve their own pages, because they have a different origin, and other uses besides. For Wikipedia use, their relevant bibliographies would also widely differ, at least at this stage. Decoy (talk) 07:06, 4 January 2018 (UTC)

The source of the two vulnerabilities is not the same. One is about branch prediction, the other not. One is an implementation issue with Intel chips only, the other is more general, and they have two names for a reason. Conflating the two doesn't help and doesn't follow the facts that they're different and one is worked-around, the other not. Although I can understand the desire to cover both together, they're different, related topics best not conflated. Widefox; talk 14:05, 4 January 2018 (UTC)

But it is: speculative execution. While the Spectre paper does center on branch prediction, it also goes in its latter part into great detail into how non-branch predictive forms of speculative execution can be exploited. From that perspective Meltdown is just one particularly deterministic means of invoking speculative execution, on a particular architecture, which leads to exploitable side effects. That's essentially why the two papers were published together, and might warrant treatment as a comprehensive whole.

Obviously I'm not going to push the issue. Especially since I'm no Wiki-native, privy to all of the rules here. But the technological is still pretty clear cut to anyone who reads the papers. Claim I. ;) Decoy (talk) 16:15, 4 January 2018 (UTC)

• Do not merge. I support Legoktm's assessment. Spectre and Meltdown are different flaws. -Mardus /talk 08:19, 4 January 2018 (UTC)
• Oppose merger at this time. I think if there were to be a single article it should be something generic like speculative execution vulnerabilities (or be contained within speculative execution) rather than mentioning both of these (somewhat contrived) names, but it looks like there is enough information for individual pages which might be linked separately from other articles. I would prefer to wait for this to play out more to see if the industry comes up with a generic label that covers both (or all three from what Google's blog post said) varieties of vulnerability, and whether the details merit individual articles in the long term. —DIYeditor (talk) 08:32, 4 January 2018 (UTC)

Agreed wrt 'speculative execution vulnerabilities', and with "at this time". It's going to go there from this, but it might be too soon for Wikipedia. Decoy (talk) 09:38, 4 January 2018 (UTC)

• Oppose: FWIW - I also oppose the merger of the two articles re security vulnerabilities (ie, "Meltdown" and "Spectre") for reasons very well described above - hope this helps in some way - in any case - Enjoy! :) Drbogdan (talk) 12:52, 4 January 2018 (UTC)
• Strong Agree(but conditional). There needs to be one "brief overview" article that discusses them simultaneously. The reasons for this are many. As parent noted, they are being treated indistinctly though they are in fact separate flaws. Further, they are taking place simultaneously. Secondly, due to the certain confusion that is going to follow, readers are either going to confuse the two or misspell spectre and look for meltdown hoping it leads to the other. Thirdly, most readers are going to want a brief summary as to the what the flaws are, what the differences are, and how it is going to affect them. They are not going to want to get into a technical overview, though there are countless programmers that are going to be looking for specifically that. Fourth, not all processors and hence computers are or will be affected (though the resultant "fixes" may adversely affect performance). There needs to be a separate article concerning what processors are affected and how the various operating systems (and versions) for them are dealing with the flaw. Fifth, there needs to be a paragraph in the main article about the legal consequences as well as a fallout from both flaws that will be difficult to deal with in the separate articles. So, there needs to be one "overview article" that can have links to the other more in depth articles. This has been done countless times on Wikipedia, and is plain as day to me here that is how editing needs to proceed now. Nodekeeper (talk) 13:44, 4 January 2018 (UTC)

• Oppose they're different flaws affecting different CPUs, although related. One is fixed worked-around, the other not. The timing is of no concern as long as they're both notable, which I believe both are. Readers are already better served with an article for each topic, and that will only get stronger as they grow. It's a WP:SNOW close. Widefox; talk 13:54, 4 January 2018 (UTC)
• Oppose They are different vulnerabilities that affect two nearly distinct sets of hardware. The potential confusion between Spectre and Meltdown to readers can be handled by noting they were publicly disclosed at the same time, and make sure links to the other are present along with why the other differs. --Masem (t) 14:28, 4 January 2018 (UTC)

I'm fine with closing this as "not merged" as it seems this isn't going to happen, though some might want to leave it open for 24 hours (there's no time requirement for merge discussions and seeing as this is a popular page, I think we'll have a visible consensus soon). Cheers, Anarchyte (work | talk) 14:32, 4 January 2018 (UTC)

I know that everyone is opposed to merging, but the structure I mentioned in my post is inevitable. If we did merge the article would be too long, and if we do not merge then eventually there will be too many disparate articles on this single subject with these two non-merged articles too long in themselves. It's like trying to avoid gravity. Nodekeeper (talk) 18:17, 4 January 2018 (UTC)

• Oppose Meltdown is an Intel specific issue, while Spectre is a "feature" of most out-of-order execution CPUs. They are tangentially related, so they should be interlinked. Artem-S-Tashkinov (talk) 16:30, 4 January 2018 (UTC)
• Oppose While those issues are somewhat similar and are discussed together, these are different issues with different affected systems, different mitigations, etc. The article itself says: "Meltdown is distinct from the Spectre Attacks in several ways, notably that Spectre requires tailoring to the victim process’s software environment, but applies more broadly to CPUs and is not mitigated by KAISER"". Let's leave them as is and cross-link. Laboramus (talk) 18:27, 4 January 2018 (UTC)
• Oppose but some combined discussion might be usefully placed at timing attack, which they are both instances of. Or a new page at speculative execution attack. Just to clarify the differences:
  • Both take advantage of the fact that when speculative execution is undone, detectable (via timing side channels) changes in cache states persist.
  • Meltdown takes advantage of speculative data: the fact that Intel delays memory access permission checking so much that it's possible to start a second speculative load whose address is a function of the data returned by a first speculative load. If the first load was forbidden (no permission to read), the data that was read can be recovered by a timing attack on the cache state effects of the second access. (There is no fundamental technical reason why the permission checking must be delayed so much; Intel just saw no reason to do it more urgently given that the speculation rewind mechanism was available and illegal loads are extremely rare in normal software so the delay had negligile performance impact. AMD made a different implementation decision and ended up immune.)
  • Spectre is exploiting speculative control flow. In the more severe variant, it has an attacking process pollute indirect branch prediction hardware in order to cause a target process to (speculatively) jump to an arbitrary attacker-controlled location in the target address space.

In both cases, the speculative operations are undone with no change to architectural state, but cache effects persist. and data can be exfiltrated via timing side channels. This is the part that's common and could be discussed in a common article. 23.83.37.241 (talk) 19:39, 4 January 2018 (UTC)

CVE Date

The article currently says "issued a Common Vulnerabilities and Exposures ID of CVE-2017-5754 in January 2018". But given that the ID has "2017" in it, the ID was clearly issued in 2017. I don't think the date of issue of the ID is important though. I think it should be reworded, probably to mention the date that the CVE was disclosed to the public. But that's already included in the History section, so maybe just drop "in January 2018" from the sentence completely. Booch (talk) 16:55, 4 January 2018 (UTC)

The relevant portion from MITRE's CVE FAQ ([2]): "A vulnerability is discovered in 2015 and a request is made for a CVE ID in 2015. The vulnerability is assigned "CVE-2015-NNNN" but not made public. (The CVE ID would appear as "Reserved" in the CVE List.) The discloser does not publish the CVE ID publicly until 2017, though. In this case, the CVE ID is still "CVE-2015-NNNN", despite the fact that the vulnerability isn't made public until 2017."

Thus issual follows the usual ethics and namespace management rules of "id sets when first allocated, not when first published". ;) Decoy (talk) 18:29, 4 January 2018 (UTC)

Affected Processors

I am trying to nail down which processors are affected. 32 bit processors are not affected and some 64 bit processors are also not affected by this as well. I will update the article as news appears, and would appreciate other editor's help. Nodekeeper (talk) 20:09, 4 January 2018 (UTC)

Evidently all 32 bit Intel processors are also affected too. Nodekeeper (talk) 03:06, 5 January 2018 (UTC)

Nit pick but fairly sure that's wrong. All reports suggest this at a minimum requires speculative execution which means the 32-bit 80386 to the Pentium will definitely not be affected. Only the Pentium Pro onwards could be affected. Our article currently mentions Atoms before 2013, I believe this is because they lack support for the specific instructions Meltdown rely on. I don't know when it was introduced but I suspect it was after the Pentium Pro. (But the Pentium Pro onwards, including the Atoms would still be affected by some of the ideas of Spectre.) Nil Einne (talk) 10:39, 5 January 2018 (UTC)

Actually apologies, I'm wrong about Atoms. Our Out-of-order execution suggests they lack that until Silvermont, which means AFAIK they couldn't have speculative execution. So that's the reason they're not affected. So being non-vunerable is not actually quite as old as the Pentium. I'm a bit confused whether or not the Quarks always have speculative execution [3] [4] Nil Einne (talk) 10:56, 5 January 2018 (UTC)

Bonnell (microarchitecture) seems to confirm all Atoms based on that lacked speculative execution. Nil Einne (talk) 11:43, 5 January 2018 (UTC)

Three Vulnerabilities, not just two?

Right now we have Meltdown and Spectre, but both Google[5] and AMD[6] indicate that there are three variants. Apparently they are all based on speculative execution. Clarification will be needed on this. Also note the case for a merge to one article (with links to secondary articles) becomes stronger. Nodekeeper (talk) 20:51, 4 January 2018 (UTC)

I indicated that there was a third variety above in the merger discussion. Couldn't any commonalities just be discussed in Speculative execution#Security vulnerabilities? That section could definitely use some expansion; I added only a brief mention. The sentiment was pretty strongly against merging the Meltdown and Spectre articles and I think there is enough content and distinctiveness for separate articles. —DIYeditor (talk) 21:33, 4 January 2018 (UTC)

Thank you for your comment. We can see how the article comes together. It appears that the Meltdown vulnerability belongs exclusively to Intel, while the the other "architecture flaw" vulnerability will belong with "out of order execution", which "speculative execution" is a subset of. So an Intel processor could potentially have all variants of the speculative execution flaws, while other processors (ARM, AMD, and whoever) would have the "architecture" flaws. Researching and listening to knowledgeable sources indicate that the latter (Spectre) appears to be the most dangerous long term as it is much harder to defend against architecturally. All three variants fall under "speculative execution vulnerablities". Also, it should be noted that all this news is coming out before the formally planned announcement on January 9th. Nodekeeper (talk) 22:49, 4 January 2018 (UTC)

Yes, there are three vulnerabilities. The Project Zero blog post explains them as:

• (Spectre) Variant 1: bounds check bypass (CVE-2017-5753)
• (Spectre) Variant 2: branch target injection (CVE-2017-5715)
• (Meltdown) Variant 3: rogue data cache load (CVE-2017-5754)

Legoktm (talk) 09:19, 5 January 2018 (UTC)

Article is factually wrong

Article states only Intel's x86 is affected. However, Apple just posted a statement here https://support.apple.com/en-us/HT208394 saying their own Ax processors are also vulnerable. --64.121.146.209 (talk) 03:20, 5 January 2018 (UTC)

Thank you for your contribution. It would be helpful if you signed up to Wikipedia with a username so we can recognize you better. Kindly note that all these vulnerabilities fall under "speculative execution", and that there are different "types" of speculative execution. Both Meltdown and Spectre belong to this type of vulnerability. Apple uses both Intel and Arm chips. When they say that Ax processors (which are similar to ARM cores) are affected, they are referring to the Spectre vulnerability. The Intel processors they use would additionally have the Meltdown vulnerability, which from cited sources, only affects Intel processors. As facts about this become more clear, the article can be changed to reflect that. Also scroll down to "Affected hardware" that goes into detail about what processors are affected. Nodekeeper (talk) 04:40, 5 January 2018 (UTC)

Accounts are lame, Wikipedia:IPs are human too. Firstly, the whole article was originally written as a bashing fest against Intel with ridiculously PoV problems. Secondly, the article assumes that P6 is affected because it has speculative execution, unfortunately that's not sufficient to make such assumption. Furthermore P6 is unlikely affected because it doesn't actually do speculative memory accesses, an enhancement that was added much later. --64.121.146.209 (talk) 05:50, 5 January 2018 (UTC)

From the link you provided you're limited as to what you can do. [[Wikipedia:IPs are human too#What an unregistered user can't do by themselves (directly). No matter, you have improved the article, and I incorporated the changes you inspired throughout. Nodekeeper (talk) 06:46, 5 January 2018 (UTC)

"Furthermore P6 is unlikely affected because it doesn't actually do speculative memory accesses" - It's not speculative memory accesses, but rather out of order execution which speculative execution is a part of. What happens is the processor tries to execute several instructions in advance. Some of these instructions can read privileged memory. When it does this, then a lower privilege process can read what the speculative branch is reading and hence gain access to higher privelege data of the speculative branch which can include passwords. This flaw is inherent to out of order speculative execution - which the P6 has. Nodekeeper (talk) 06:57, 5 January 2018 (UTC)

ARM published a statement which says that the A75 is vulnerable to meltdown, and that A15, A57, and A72 are vulnerable to a variant of meltdown. But then they also say that for the chips affected by the variant, that no software mitigation is necessary. Legoktm (talk) 09:28, 5 January 2018 (UTC)

First paragraph craziness

The first paragraph does not follow Wikipedia's style guide for the lead paragraph WP:LEAD, and I would appreciate other editor's help in reverting it back, or drastically shortening in a manner that follows WP:LEAD. The editor who changed it, besides not following WP:LEAD is not discussing in talk as requested and they are not working towards WP:CONSENSUS. Nodekeeper (talk) 08:13, 5 January 2018 (UTC)

Intel CEO Krzanich's maximal unexplained stock sale after notification

Gallagher, S. (January 4, 2017) "Intel CEO sold all the stock he could after Intel learned of security bug" Ars Technica

Brian Krzanich, chief executive officer of Intel, sold millions of dollars' worth of Intel stock—all he could part with under corporate bylaws—after Intel learned of Meltdown and Spectre, two related families of security flaws in Intel processors. While an Intel spokesperson told CBS Marketwatch reporter Jeremy Owens that the trades were "unrelated" to the security revelations, and Intel financial filings showed that the stock sales were previously scheduled, Krzanich scheduled those sales on October 30. That's a full five months after researchers informed Intel of the vulnerabilities. And Intel has offered no further explanation of why Krzanich abruptly sold off all the stock he was permitted to. As a result of his stock sale, Krzanich received more than $39 million.

I would like to see that summarized in the article. YATA 123 (talk) 12:01, 5 January 2018 (UTC)

There's really not that much information in the arstechnica link you sent. Basically "SEC officials could still see the maneuver as a trade based on insider information—especially if there was no other material reason for Krzanich to sell the stock." The big word there being IF. Scandal is exciting nonetheless.

I apologize for dismissing this based only on 1 link... There are lots of other links that suggest that this is somehow Intel's fault in a big way:

https://www.wsj.com/articles/intel-wrestled-with-chip-flaws-for-months-1515110151 https://investorplace.com/2018/01/intel-corporation-intc-should-fire-brian-krzanich/ https://www.prnewswire.com/news-releases/kaplan-fox-announces-investigation-of-intel-corporation-300578289.html

But again there are lots of IFs. I'm going to stick with Because Google here. Until we get more info about how maybe Intel screwed up somewhere. — Preceding unsigned comment added by 108.185.180.195 (talk) 17:29, 5 January 2018 (UTC)

What about Google?

How about mentioning the downside effects to Google investors that will now occur due to them having to pay for a new more expensive CPU. Let's call it Xuthenia. Priced 2X higher than Xeon. Today, if you want ECC and more memory, you pay 2X for Xeon. In 2021, if you want super-KTPI(TM) you pay 4X for Xuthenia! It's the only way to prevent microgammawave stethoscope attacks. I can see Intel revenues going through the roof, at the expense of Google investors. — Preceding unsigned comment added by 108.185.180.195 (talk) 17:16, 5 January 2018 (UTC)

Possibly anticipated by the OpenBSD developers on 2007

This posting to the OpenBSD mailing lists regarding flaws on Intel CPUs may be related to Meltdown. The errata doc mentioned is still reachable in archived form here. --Tactica (talk) 17:33, 5 January 2018 (UTC)