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)

Bad explanation

The explanation as of now reads as follows:

1. The CPU attempts to execute an instruction referencing a memory operand. The addressing mode requires the operand's address, Base+A, to be calculated using the value at an address, A, forbidden to the process by the virtual memory system and privilege check. The instruction is scheduled and dispatched to an execution unit. This execution unit then schedules both the privilege check and the memory access.

2. The privilege check informs the execution unit that the address, A, involved in the access is forbidden to the process (per the information stored by the virtual memory system), and thus the instruction should fail. The execution unit must then discard the effects of the memory read. One of those effects, however, can be caching of the data at Base+A, which may have been completed as a side effect of the memory access before the privilege check – and may not have been undone by the execution unit (or any other part of the CPU). If this is indeed the case, the mere act of caching constitutes a leak of information in and of itself. At this point, Meltdown intervenes.[45]

3. The process executes a timing attack by executing instructions referencing memory operands directly. To be effective, the operands of these instructions must be at addresses which cover the possible address, Base+A, of the rejected instruction's operand. Because the data at the address referred to by the rejected instruction, Base+A, was cached nevertheless, an instruction referencing the same address directly will execute faster. The process can detect this timing difference and determine the address, Base+A, that was calculated for the rejected instruction – and thus determine the value at the forbidden memory address A.

This is too wordy, but more importantly, is WRONG in many places:

"The addressing mode requires the operand's address, Base+A, to be calculated using the value at an address" is totally wrong - the first access can use any adressing mode, what's important is that it should read from an address which attacker wants to kow, but is not allowed to. It's the *second* access should use this data to index into cache probing array. "The instruction is scheduled and dispatched to an execution unit." Why this even needs to be said? To make article longer? Next wrong bit: in the above, *where is* the second speculative load, the one which creates the caching side effect? The fact that first access is likely to also cache its result is immaterial to the exploit, since discovering that _that_ location is cached is not possible. For exploit to work, you need to _use_ the obtained speculative value while you can.

I'm replacing it with:

1. The CPU is instructed to read data (for example, one byte) at address which current process is not allowed to access. The read is speculatively executed but its result, A, is not saved in visible architectural state of the CPU. (The data would become visible later, if access check confirms that access to this particular address is allowed).

2. The CPU continues speculatively executing and now it is instructed to read read a normally accessible memory area using addressing mode Base+A, to be calculated using the value A at the address speculatively accessed in step 1. This second read is also speculatively executed. This causes caching of the Base+A location.

3. When result of the instruction in step 1 attempts to complete and be saved in visible architectural state of the CPU (attempts to "retire"), retirement logic detects that access was not allowed - and therefore this and all subsequent instructions' results are discarded. However, effect of caching of the data at Base+A is not undone (caching is not "architectural state"). The mere act of caching constitutes a leak of information in and of itself.

4. The process executes a timing attack by measuring how fast elements of Base[x] array can be accessed. If the data at the address Base+A is cached, and all other elements Base+x are not, only instruction referencing Base+A execute faster. The process can detect this timing difference and determine the value of A obtained by the rejected instruction of step 1 – and thus determine the value at the forbidden memory address.

User Twinkle reverted my edit. I would like to discuss it here. I think my version is not simply better worded - it is CORRECT, whereas previous one is wrong.

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 vulnerability)" - 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)
• Support (changed from Oppose but)

After having discussed and descried the issue to several people, I have changed my mind, and now believe the commonalities are greater than the differences. In particular, the official description of the attacks themselves talk about variants 1,2,and 3, with 1 and 2 being Spectre and 3 being Meltdown. I think it's easier to describe the basic problem of speculative execution + cache timing side channel once, and then point out the various ways it is applied. By doing this on one page, rather than duplicating the explanation on two, I believe readers would understand better. (This is the part based on my experience talking to people.)

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) Changed from Oppose to Support 23.83.37.241 (talk) 22:01, 5 January 2018 (UTC)

We have a location for that, Speculative execution#Security vulnerabilities. —DIYeditor (talk) 22:28, 5 January 2018 (UTC)

• Oppose (oppose the merge, I support the current separation of article) The reasons that I oppose/support are because: (a, oppose) On the technical level, they are literally different species. (b, support) News articles and source materials do group them together, (c, oppose) as per Wikipedia guidelines regarding appropriate structure, I believe they should be kept as complete separate articles. (d, oppose) Maybe as time moves past the patch/work-arounds/etc. of these security vulnerabilities, it might make sense at that time to merge them but for now we do not know what paths they will take and joining them may be a waste if a future event causes them to separate. That's my bit. 134.186.234.108 (talk) 16:20, 10 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)

If this is relevant to the confusing phrasing (and what looks to be inaccuracy – it doesn't include all Microsoft Windows devices, since it's a hardware vulnerability?), I've tried to clean that up just now. Throne3d (talk) 17:40, 5 January 2018 (UTC)

Thanks for your help. The lead reads much better now. Technically it's not all Microsoft Windows devices because Windows has been ported to other devices that don't have Intel CPUs e.g. their Surface tablets use processors with the ARM cores, not all of which are vulnerable (unlike Intel's where nearly all are). But Microsoft does hold the majority for installed OS desktops. So someone could say "all Microsoft Window's desktops" and be correct, but not "all Windows devices". Nodekeeper (talk) 18:17, 5 January 2018 (UTC)

No problem! I meant more – can't you have an AMD desktop running Microsoft Windows, which wouldn't be affected because it doesn't run affected hardware? Throne3d (talk) 19:36, 5 January 2018 (UTC)

I have a feeling that we are all going to become microprocessor branch pipelining experts by time this thing is done!:D So AMD is in fact vulnerable to one of the Spectre variants but not Meltdown which really hits Intel. The Spectre variant is actually a "structural" flaw and not a "microcode" programming flaw like Meltdown is. Here is a very good article covering AMD processors. AMD managed to get out ahead in the PR battle and looks good even though some of their processors (e.g. the FX line) are in fact vulnerable to Spectre which actually is the more problematic of the two bugs. So, if you wanted to plug in a computer today and not be vulnerable then you would need to look at the Raspberry Pi computer (which a few people do run as a minimal Linux desktop). Or find a tablet that has an ARM processor not on the vulnerable list. However, Microsoft and Linux will be rolling out patches to their operating systems soon, but it will have the performance hit from the Specter fix that everyone is talking about until the google fix is implemented wide scale. I think Linux may beat Microsoft to this because the Google team implemented their fix into the GCC compiler already. As an aside, it's kinda a laugh because in one of the forums not too long ago before these vulnerabilities became known users were discussing why Linux is not on the desktop more a number of posters were criticizing the GCC compiler heavily because it doesn't do a good job of program optimizing for out of order execution - which is the part responsible for Spectre! Also as time goes on it is possible that other types of out of order execution vulnerabilities could be found (especially in other processors not mentioned yet), which the problem ARM variants demonstrate. Nodekeeper (talk) 03:44, 6 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)

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)

In a detectable manner

Should probably be "in an indetectable manner" ? --Tactica (talk) 19:49, 5 January 2018 (UTC)

Actually what there is correct, although confusing. To paraphrase what it is saying that when the privileged program does program reads in the speculative execution branch, it does so in a "detectable manner" by a lower privileged program. The flawed microprocessor checks privileges *after* speculative execution, allowing the lower privilege program access until it does so. AMD avoided this fault because they check privilege *before* speculative execution takes place and hence the lower privilege program is not able to detect the data in the higher privileged speculative execution branch. Nodekeeper (talk) 02:00, 6 January 2018 (UTC)

I still find it quite confusing but I do get the gist of it. I followed suit in the spanish translation anyway, thanks! :) --Tactica (talk) 17:53, 6 January 2018 (UTC)

Array accessibility in exploit example

The 5000's array should be accessible to the rogue process. It will need to access it to measure the access time. Point nine should end with: So even though the instruction itself failed, and even though the process cannot directly read the contents of address 2000, the rogue process can still use its side-channel attack to identify that address 5004 is in the cache and the other addresses between 5001 and 5005 are not, so it can still determine that the second address that the instruction would have tried to read is 5004, and therefore that the content of unauthorized address 2000 is "4". 69.12.251.25 (talk) 19:57, 5 January 2018 (UTC)

History - possible earlier source of known vulnerability found

In the History section about who discovered and/or made a possible vulnerability public the following might be useful information. On a link to is provided, page dated at 07-28-2017, which describes in quiet some detail a possible vulnerability approach, with simple code samples showing an effect. The author did not came up with a fully working exploit, but his assumptions are exactly the same as implemented in the meltdown attack later. If the page date is right, which i cannot confirm/deny, the Author should at least be credited somehow. This info is public for over 5 months now. Is there a way to check if a webpage is really as old as it states? thanks. 91.5.148.221 (talk) 00:34, 6 January 2018 (UTC)

There is this reuter's article [7] that goes into detail about how the discovery unfolded. Evidently there was a paper that was written last June, and the reuter's article seems to insinuate that the bug was discovered the previous December before that in 2016. Nodekeeper (talk) 02:19, 6 January 2018 (UTC)

Yes, you can browse old versions going back to at least July 28, 2017 on the Wayback Machine (frequently used for demonstrating prior art in patents, for example):

The 07/28/2017 version definitely outlines the use of a cache timing attack to observe the results of speculative operations conditioned on data fetched with invalid privileges. Sounds a lot like Meltdown to me. Definitely should have been referenced.

References

Meltdown vulnerability status of Intel socket 478/775 and Via C7/C7m CPU?

Is there anything definitive or proven about the vulnerability status of any of the Intel socket 478/775 based CPU's to meltdown? Have those CPU's been specifically tested? What about Via's line of x86 processors (C7/C7M) ? — Preceding unsigned comment added by 198.2.94.117 (talk) 16:15, 6 January 2018 (UTC)

I too am curious about the vulnerability status of Via CPUs. I noticed that the articles on both Meltdown and Spectre appear to not mention Via at all, as if Intel and AMD are the only brands of 80686 and x86-64 CPUs. Brolin Empey 09:20, 10 January 2018 (UTC) — Preceding unsigned comment added by Brolin Empey (talk • contribs)

I checked /proc/cpuinfo on Linux kernel 4.15 on an HP 2133 Mini-Note PC with VIA C7-M CPU, which is apparently vulnerable to both Meltdown and Spectre, as shown in this screenshot. Can anyone check on VIA Nano, the x86-64 successor to the 80686 C7? Brolin Empey 20:56, 31 October 2018 (UTC) — Preceding unsigned comment added by Brolin Empey (talk • contribs)

methods of accessing the info in the cache?

The article says "data from the unauthorized address will almost always be temporarily loaded into the CPU's cache during speculative execution, from which it can be recovered using other techniques,". Can we link to what those other methods are? RJFJR (talk) 19:59, 7 January 2018 (UTC)

I have created a Cache side-channel attack redirect to help with this. The gory details are actually in the The Meltdown exploit section. Thanks and kudos to whomever contributed this material. This is the first place I've seen a complete technical description of the side-channel mechanism used by Meltdown. ~Kvng (talk) 18:11, 8 January 2018 (UTC)

The referenced meltdown document (meltdown.pdf) is unreadable.

This article references the document meltdownattack.com/meltdown.pdf but I have yet to find a pdf reader that can render it properly. How was this document formatted? Can it be recomposed such that it is actually readable in a standard pdf viewer? — Preceding unsigned comment added by 198.2.94.117 (talk) 00:06, 8 January 2018 (UTC)

FWIW - PDF (ie, https://meltdownattack.com/meltdown.pdf ) seems fine w/ my dell xps8930/windows10/google chrome/adobe acrobat extension computer - hope this helps in some way - in any regards - Enjoy! :) Drbogdan (talk) 01:49, 8 January 2018 (UTC)

The only problem I had with it was that the letters were too small for me to read easily. That can be quickly fixed by clicking on the + button which makes the image larger, although at the cost of not having an entire page on the screen at one time. Was that what you meant? JRSpriggs (talk) 03:39, 8 January 2018 (UTC)

Impact of Meltdown on single-user devices / PC's vs Servers?

Is the primary threat of the Meltdown vulnerability to multi-user servers? Is Meltdown a practical threat for single-user PC's in a home or SOHO situation (ie non-institutional, non-enterprise)? Can meltdown be leveraged on such systems without needing to use other exploits to get it running on remote target systems and report any results back to the attacker? — Preceding unsigned comment added by 198.2.94.11 (talk)

There is discussion of the potential for a Javascript exploit which would allow a web page you visit to read and report anything lying around in memory - recently-used passwords and financial information, browse and other activity history. There is no indication that anyone has yet produced such an exploit but I'm sure they're working on it. ~Kvng (talk) 18:16, 8 January 2018 (UTC)

Doesn't this issue of "discovering passwords" require sifting through megabytes of ram and hitting upon a short sequence of bytes that "looks like a password"? Is there something about how a password is stored in RAM (Kernel ram or User ram) that makes it easier than I'm imagining finding it? And how would be it known what it is a password to? And how would it be tested if it were a logon password for the system being scanned?

Hackers are motivated and clever and what seems improbable but clearly possible is readily accomplished. I'm not sure exactly what's going on here but I've seen several of these sorts of demonstrations now. ~Kvng (talk) 16:30, 9 January 2018 (UTC)

You may think that there are a lot of 15 character strings in your core memory, but it is not nearly as many as the number of random 15 character strings which are possible. JRSpriggs (talk) 21:28, 9 January 2018 (UTC)

Misleading focus on Apple products in the introduction

The introduction second paragraph currently starts with "Meltdown affects a wide range of systems. At the time of disclosure, this included all iOS and Mac devices, in addition to...".

Correct me if I'm wrong but since this vulnerability affects most CPU and OS in circulation, iOS and Mac devices should represent only a very small fraction of the affected devices and users.

Shouldn't the introduction be rewritten in order to focus on the wide range of affected devices before mentioning any specific brand or product (if that's even relevant) ? As currently written, the paragraph may leave a hasty reader to think that Meltdown affects mostly iOS and Mac devices which seems to be far from the truth.

The rest of the article (including the "Affected Hardware" and "Impact" sections) doesn't currently make any mention of those Apple products, nor does it give a clear insight on the proportion of specific consumer products that are affected.

Zakinster (talk) 16:36, 8 January 2018 (UTC)

That's a good point, but not for the reasons you mention. Editors need to make the distinction that the vulnerabilities are first in and affecting microprocessors which then in turn affect the operating systems they run on and in turn the programs that run on the operating systems. From two important standpoints - a security standpoint and a performance standpoint. Besides that there are a couple of grammar mistakes in the lead.

By Apple's own admission though, the vulnerabilities are affecting all their machines. Then you need to make the analysis of what percentage of Apple hardware represents the installed base of computer users. The last time I saw a valid pie chart, they were second behind Microsoft. So, by either account it's not a "small" number as you might would contend, but I do think your editing criticisms in general are otherwise valid. Though you need to recognize that this is an ongoing and evolving story and as we find out more the article will change. That said, I am noticing the trend that as time goes on this thing is getting bigger and it is encompassing more hardware and becoming more problematic both from a supplier trying to mitigate the problem and and an end user that doesn't want to be vulnerable. Nodekeeper (talk) 20:58, 8 January 2018 (UTC)

First off, Windows is also mentioned in the same sentence. Second, I'm not sure you can read, "are affecting all their machines" from the reference used in the lead. That source goes on to explain that Apple had already released some mitigations before the disclosure. I agree we should focus on processors first and on OS mitigations second. We need a new paragraph in the lead describing mitigations and I assume there will be no objection to talking about Apple products in that :) ~Kvng (talk) 21:45, 8 January 2018 (UTC)

My only objection to that is that we don't end up with another ghastly lead section like we suddenly had before that takes up half the page. I couldn't revert it because I ran out of reverts and had to throw up a template to get it fixed. (see WP:LEAD ). BTW, Apple has just barely released another patch (about which the details are not clear yet), and Microsoft's patch are killing AMD machines. Tomorrow Jan 9th was supposed to be the day that large announcements were planned before we had the leaks because of the patches to the Linux kernel. This appears to be a very fluid news event, so I think we should wait a couple of days maybe the weekend before we make drastic changes. But I otherwise think your editing decisions are on track. Nodekeeper (talk) 23:26, 8 January 2018 (UTC)

The cited "iOS and Mac devices" seems to only represent ~12% and ~8% of their respective market share : for personal computers, Apple MacOS may be second in OS market share but with only ~8% (after Microsoft Windows, ~89%), they are actually 5th in computer constructor (after Lenovo, HP, Dell and ASUS) with only 7% market share and there's no reason to think that those 4 other major constructors are not equally affected. For mobile devices, their OS is second with ~12% (after Android, ~88%)and their devices seems to be also second with ~15% (after Samsung, ~21%). Zakinster (talk) 08:58, 10 January 2018 (UTC)

References

Number of cache attacks is wrong

The article states:

In practice because cache side-channel attacks are slow, it's faster to extract data one bit at a time (only 2 × 8 = 16 cache attacks needed to read a byte, rather than 256 steps if it tried to read all 8 bits at once).

But the actual number of cache attacks to read one byte should be 8, not 16. For example if we try to discover the value of the bit 0, by accessing the location 5000 + bit0, if the bit is 0, 5000 will be read, and when we measure the speed of the location 5000, will be fast because is in cache, however if it's slow, we don't need to measure 500 Because we can automatically assume that if a bit is not 0, will be 1. — Preceding unsigned comment added by Maury91 (talk • contribs) 23:56, 9 January 2018 (UTC)

Finding a CPU Design Bug in the Xbox 360, story from 2005

Finding a CPU Design Bug in the Xbox 360 by Bruce Dawson: in 2005, Bruce had an issue with CPU speculative execution while working on the Xbox 360 CPU. "And that was the problem – the branch predictor would sometimes cause xdcbt instructions to be speculatively executed and that was just as bad as really executing them." It's more like a CPU bug than a security bug, but it's good to know that some engineer knew issues with CPU speculative execution, even if they didn't think as the bug as a covert channel. -- Haypo (talk) —Preceding undated comment added 00:11, 10 January 2018 (UTC)

This is the purpose that I got from what you wrote: Meltdown is a CPU bug that is also a security vulnerability. Interesting, but I am unsure what to do about this information. 134.186.234.108 (talk) 16:30, 10 January 2018 (UTC)

2010: failed attempt to attack CPU speculative execution

In 2010, Joanna Rutkowska and Rafał Wojtczuk tried to attack CPU speculative execution for code execution at Invisible Things Lab but "never got anywhere":

• https://twitter.com/rootkovska/status/948997805158338560
• https://twitter.com/rootkovska/status/895954342943084544

The attempted attack didn't try to exploit covert channel, but expected that privileged instructions would be executed in advance (speculated), and that some data could be stolen from that. But it's not the case.

It's not like nobody audited CPU speculative execution in past years. -- Haypo (talk)

Would this indicate that CPU's available at the time (2010) were not vulnerable? Would be nice to get a handle on the vulnerability status of older CPU's going back to socket 478/775 versions. — Preceding unsigned comment added by 198.2.94.117 (talk) 14:36, 11 January 2018 (UTC)

No, it only indicates that some security researchers were aware of the speculative execution and tried to exploit it. They didn't try to find a covert channel. -- Haypo (talk) 14:54, 11 January 2018 (UTC)

2012: Detect and mitigate microarchitectural side channels, Simha Sethumadhavan

Bjoern Michaelsen: Intel was apparently in the know on this specific attack vector since at least 2012 (via fefe): https://mobile.twitter.com/TheSimha/status/949361495468642304

Simha Sethumadhavan: "Slide from a talk I gave at Intel (and many other places) 6 years back. The talk was on design time tools and techniques to detect and mitigate microarchitectural side channels (Side Channel Vulnerability Factor measurement and method, and the TimeWarp mitigation from ISCA12)." https://mobile.twitter.com/TheSimha/status/949361495468642304

• http://www.cs.columbia.edu/~simha/preprint_isca12_svf.pdf
• http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf

-- Haypo (talk) —Preceding undated comment added 01:44, 10 January 2018 (UTC)

Detailed timeline by Jan Wildeboer

How we got to #Spectre and #Meltdown A Timeline: https://plus.google.com/+jwildeboer/posts/jj6a9JUaovP

-- Haypo (talk) —Preceding undated comment added 01:48, 10 January 2018 (UTC)

Intel microcode update released (for Linux)

Download page

Maybe someone would be so kind to reflect that in the article? :) For the time being I'm not aware of any updates specifically targetted at other operating systems.--Tactica (talk) 10:14, 11 January 2018 (UTC)

Could "Mechanism" be condensed?

There is a lot to read there, and it seems like the mechanism isn't all that complicated. I might be missing something. Here is my understanding after reading it:

• A malicious process wants value (X) at address W, which it isn't supposed to have access to.
• Process tells CPU to get value at Y+(value at W) (indirect addressing), where Y is an arbitrary base address.
• The CPU fetches Y+X while checking privileges to it (this stores a value in the cache for Y+X).
• Requests are then made directly for Y+Z, where Z is all possible values of X (this range is determined by the size of X).
• If request is faster, then it was cached, and we know that X = Z. (This is where cache timing comes in).
• Effectively we fetched the value at W (though it was privileged)
• This process can be repeated for other values of W (using a different Y, though, so it doesn't accidentally hit the cache).

Does that seem right? If not, something could be added to the section to clarify what I misunderstood.

Also, it would be good to have some explanation of how this is a RACE condition. From what I see, both the events the scheduler creates happen without interfering with each-other.

Thanks! — Preceding unsigned comment added by Snydergd (talk • contribs) 13:33, 15 January 2018 (UTC)

I agree that the Mechanism section is conversational and that's generally frowned on. You have summarized it but I think a bit too aggressively so I don't think I would have understood your summary if I had not first read the full Mechanism section. Also your description tend toward WP:HOWTO which is generally frowned on. I think it would be best to attempt a copyedit pass on the existing material. If that is too difficult to get through or does not improve things significantly, it would be then time to consider a rewrite. ~Kvng (talk) 16:50, 15 January 2018 (UTC)

Which microprocessor family/microprocessor families?

In sub section Overview:

... as there is little to no variation in the microprocessor family used by these computers ...

What does this mean? What microprocessor family is referred to (or it could be "... the microprocessor families...")? Variation in what?

--Mortense (talk) 14:51, 15 January 2018 (UTC)

The so called vulnerability is merely speculative

Sigh, yet another so called security vulnerability got blown out of proportion completely. — Preceding unsigned comment added by 218.103.26.1 (talk) 03:39, 17 January 2018 (UTC)

is this a Speculative execution joke? ~Kvng (talk) 15:22, 20 January 2018 (UTC)

Date format

The dates were in 3 different formats. I made them all DMY[8] and Drbogdan reverted[9] making them again 3 different formats. I think we should go with DMY because this article is of international interest. At the least they should be made consistent throughout the article. —DIYeditor (talk) 21:16, 18 January 2018 (UTC)

By MOS:DATERET we should keep the first date style used in the article which appears to be DMY[10]. There were hyphenated Y-M-D dates in references before then but that is not one of the two choices for spelling out a date in the body of the article. —DIYeditor (talk) 21:22, 18 January 2018 (UTC)

@DIYeditor: Yes - agreed - please understand that I have no problem whatsoever with the dating format used - seems the original "MDY" template (ie, {{use mdy dating|date=January 2018}}) was added on "08:31, 4 January 2018" - at that time, all the reference dates were adjusted to "conform to this format" - however - this could all be adjusted/updated to whatever format you like of course - in any case - Enjoy! :) Drbogdan (talk) 21:45, 18 January 2018 (UTC)

Doesn't matter much as long as it's consistent. Let's wait and see if anyone else has an opinion. —DIYeditor (talk) 00:05, 19 January 2018 (UTC)

@DIYeditor:  Done - updated/adjusted all dates to the originally noted "MDY" template - can always adjust to some other date format of course - but all ref dates are now one format - at least at the moment afaik - in any case - Enjoy! :) Drbogdan (talk) 19:31, 26 January 2018 (UTC)

 Done @DIYeditor: FWIW - updated all dates in the "Meltdown (security vulnerability)" main article to the "DMY" format after all - seems better - in any case - Enjoy! :) Drbogdan (talk) 13:27, 4 June 2019 (UTC)

Excellent description of the bug

Clear yet technical. Not journalistic woffle. Not masses of irrelevant detail. Not a reference in it, but well done. Thanks. Tuntable (talk) 23:57, 22 January 2018 (UTC)

affected hardware section, initial intel statement

The initial intel statement that all processors are affected is not wrong as (clever) Intel did not separate between Meltdown and Spectre but was talking about all security issues found, merging Meltdown and Spectre in one sentence. Maybe the sentence could be reworded to better reflect this.--Denniss (talk) 12:53, 20 March 2018 (UTC)

Total Meltdown in Win7

Not amusing, see [11]. Soemone with better language skills please include in article as side effect. --Denniss (talk) 16:49, 28 March 2018 (UTC)

Alarmist rhetoric

The article here seems excessively inaccurate and a bit alarmist. The lead-in claim "It allows a rogue process to read all memory, even when it is not authorized to do so." is not supported by research. AlsoMostlyHarmless (talk) 16:25, 30 March 2018 (UTC)

If you have a citation to a reliable source that contradicts the many reliably sourced statements in the article that do not support what you claim, by all means, add the info. Anastrophe (talk) 01:18, 1 April 2018 (UTC)

Please justify statement in intro about smart devices

The intro to the article says "majority of smart devices and embedded devices using ARM based processors (mobile devices, smart TVs, printers and others), including a wide range of networking equipment." I find this statement hard to justify. At the time of the announcement the only CPU core from ARM ltd that was vulnerable to meltdown was the A75 and not many devices (if any) were in the filed with that core. I understand that Apple and others make their own ARM cores. The statement above may or may not be applicable to iPhones or AppleTV; I don't know. However the market described by the statement is much bigger than just Apple products. Such a blanket statement should be justified with a citation. It is my belief that the vast majority of Android phones, smart TVs, printers, routers, etc were not susceptible to Meltdown.

Please note that this article is about Meltdown and not Spectre. Also not that Vulnerability "3A" as published by ARM is not meltdown as described by this article. Vulnerability 3A lets you read the value of a control register not memory and ARM does not recommend any mitigation. Please read the ARM info already cited in this article. WmMills (talk) 15:15, 29 September 2018 (UTC)

The description of how exploit works is incomplete

The description describes how the exploit determines if data at an address of interest is cached successfully and then follows by saying the process can "thus determine the value at the forbidden memory address". There is a long way between knowing particular data has been cached and knowing the actual value of the data.

The original Meltdown paper refers to Flush+Reload attack as an example of data extraction from the cache, but that technique depends on another process's manipulation of that data at the same time in a very particular way. It is by no means a generic "read everything we have in the cache" mechanism.

The Meltdown paper claims it is possible to read any value from a forbidden address, but that statement is misleading. Although the data from the forbidden memory address has been read into cache (when it shouldn't) it remains inaccessible to the attacker unless another mechanism is used to retrieve it. This should be made clear in the exploit description. — Preceding unsigned comment added by LukMF (talk • contribs) 10:24, 8 March 2021 (UTC)

"Meltdown (security vulnerability" listed at Redirects for discussion

The redirect Meltdown (security vulnerability has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 March 3 § Meltdown (security vulnerability until a consensus is reached. Utopes _{(talk / cont)} 18:17, 3 March 2024 (UTC)

poor choice of words

in the "background" part where it explains how the computer lays its ram out, i feel like it could be worded better because currently it says stuff "cohabits" the computers memory, but i am not sure how it can be worded better - some bored kid at school 21:25, 2 April 2024 (UTC)

I don't see the word 'cohabit' anywhere in the article...? cheers. anastrophe, an editor he is. 23:45, 2 April 2024 (UTC)

i forgot to put a dash in between co and habit, it is spelt "co-habit" in the article - some bored kid at school 00:19, 3 April 2024 (UTC)

Thanks. I'll try and work on it later, the whole thing has a mess of emotive wording, e.g. "each process is given the impression", stuff like that. It should be characterized as analogy rather than bare. cheers. anastrophe, an editor he is. 01:15, 3 April 2024 (UTC)

Actually, this is a hornets nest of shortcomings that would rapidly both consume all my time, and do so ineffectively, as I'm not a subject matter expert here. I'll have to leave it to others to clarify the wording. cheers. anastrophe, an editor he is. 04:48, 3 April 2024 (UTC)