![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
![]() |
Daily pageviews of this article
A graph should have been displayed here but
graphs are temporarily disabled. Until they are enabled again, visit the interactive graph at
pageviews.wmcloud.org |
Please merge this article with Kernel page-table isolation. - Mardus / talk 22:18, 3 January 2018 (UTC)
The explanation as of now reads as follows:
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:
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.
I don't see an article about Spectre (security bug) Artem-S-Tashkinov ( talk) 23:59, 3 January 2018 (UTC)
The result of the move request was: Already moved by Legoktm. Anarchyte ( work | talk) 05:39, 4 January 2018 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Should probably be "in an indetectable manner" ? -- Tactica ( talk) 19:49, 5 January 2018 (UTC)
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)
In the History section about who discovered and/or made a possible vulnerability public the following might be useful information. On [1] a link to [2] 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)
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
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)
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)
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)
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)
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)
References
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 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)
In 2010, Joanna Rutkowska and Rafał Wojtczuk tried to attack CPU speculative execution for code execution at Invisible Things Lab but "never got anywhere":
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)
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
-- Haypo ( talk) —Preceding undated comment added 01:44, 10 January 2018 (UTC)
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)
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)
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:
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)
In sub section Overview:
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)
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)
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)
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)
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)
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)
Not amusing, see [11]. Soemone with better language skills please include in article as side effect. -- Denniss ( talk) 16:49, 28 March 2018 (UTC)
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)
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 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)
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)
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)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
![]() |
Daily pageviews of this article
A graph should have been displayed here but
graphs are temporarily disabled. Until they are enabled again, visit the interactive graph at
pageviews.wmcloud.org |
Please merge this article with Kernel page-table isolation. - Mardus / talk 22:18, 3 January 2018 (UTC)
The explanation as of now reads as follows:
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:
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.
I don't see an article about Spectre (security bug) Artem-S-Tashkinov ( talk) 23:59, 3 January 2018 (UTC)
The result of the move request was: Already moved by Legoktm. Anarchyte ( work | talk) 05:39, 4 January 2018 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Should probably be "in an indetectable manner" ? -- Tactica ( talk) 19:49, 5 January 2018 (UTC)
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)
In the History section about who discovered and/or made a possible vulnerability public the following might be useful information. On [1] a link to [2] 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)
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
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)
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)
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)
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)
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)
References
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 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)
In 2010, Joanna Rutkowska and Rafał Wojtczuk tried to attack CPU speculative execution for code execution at Invisible Things Lab but "never got anywhere":
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)
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
-- Haypo ( talk) —Preceding undated comment added 01:44, 10 January 2018 (UTC)
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)
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)
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:
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)
In sub section Overview:
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)
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)
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)
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)
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)
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)
Not amusing, see [11]. Soemone with better language skills please include in article as side effect. -- Denniss ( talk) 16:49, 28 March 2018 (UTC)
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)
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 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)
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)
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)