Jump to content

Talk:Spectre (security vulnerability)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Created talk-page

[edit]

Created the talk-page for the Spectre (security vulnerability) article - Enjoy! :) Drbogdan (talk) 00:43, 4 January 2018 (UTC)[reply]

This is now the talk-page for the Spectre (security vulnerability) article - Enjoy! :) --Stefan2904 (talk) 03:00, 4 January 2018 (UTC)[reply]

Move discussion in progress

[edit]

There is a move discussion in progress on Talk:Meltdown (security bug) which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 01:01, 4 January 2018 (UTC)[reply]

The discussion has been closed. The page was moved. EdTocino1 (talk) 02:35, 4 January 2018 (UTC)[reply]

Ways to mitigate

[edit]

I'd like to add this:

Since the vulnerability can be exploited via JavaScript from a browser, then browsers equipped with scriptblocking add-ons, such as Firefox with NoScript, would be least affected. Browsers with only an adblocker and its up-to-date blocklists could mitigate the issue, but not as strongly as with NoScript, because adblockers use blacklists, while NoScript uses whitelists.

Unfortunately, this would be original research until a reputable source will suggest it. -Mardus /talk 06:11, 4 January 2018 (UTC)[reply]

I don't think Firefox privacy.firstparty.isolate is a mitigation; it only prevents websites from accessing one another's cookies. It is not a website process isolation like Chrome's site-per-process. Rakerman (talk) 01:59, 6 January 2018 (UTC)[reply]

Internet

[edit]

This only applies to Internet-connected computers (or maybe ones otherwise connected to such, as through thumb drives). That should be made explicit 87.247.33.223 (talk) 11:52, 4 January 2018 (UTC)[reply]

how so? it affects any computers, whether they are connected to the internet, intranet, or not connected at all.--vityok (talk) 14:20, 4 January 2018 (UTC)[reply]
Yes, unconnected computers can have the vulnerability, but it is irrelevant to them since it cannot be exploited in them (unless someone physical gets a hold of the computers). Kdammers (talk) 15:06, 4 January 2018 (UTC)[reply]
By that token any and all security bugs would be "only internet-related", because you always have to have some way of putting exploitative software into a computer, you know, to exploit it.
Spectre can be introduced via any vector which handles software at all. USB, diskette, firmware, an IR port, or even by a single malicious hand. So no, it ain't internet-specific at all. Decoy (talk) 15:45, 4 January 2018 (UTC)[reply]
I disagree that this applies to internet-only-connected computers, and instead agree with statements made by vityok, Kdammers and Decoy. Example: If one had a computer connected to their home wifi (which is not connected to the internet), a guest could connect and host a website that when accessed by the resident on their computer would be vulnerable to any Spectre on such site. The internet is only related to this vulnerability, as the existence of a helicopter is to a zombie infested area - I hope this helps clarify why the internet is technically unrelated, although it does create higher risk of exposure. 134.186.234.108 (talk) 22:45, 9 January 2018 (UTC)[reply]
Additionally I would like to add that there is hardly a definition of "vulnerability" which requires the system to be connected to the Internet or any other data transmission channel. Both Spectre and Meltdown breach expected system behaviour and gain unauthorized access to the information that is expected to be protected. And finally: Stuxnet.--vityok (talk) 12:09, 10 January 2018 (UTC)[reply]
I agree with you vityok and you clarified it in my mind: The bottom line is that hardware appeared to have met objectives, but there is now proof that it did not; specifically the most critical security objectives are not met in certain scenarios. Data transmission, as vityok says, can be used in conjunction with this insecure situation to transmit sensitive/confidential/etc. information via the data transmission. 134.186.234.108 (talk) 16:02, 10 January 2018 (UTC)[reply]

llvm

[edit]

this seems to be the llvm patches that are being prepared to counter some of this.. —TheDJ (talkcontribs) 16:09, 4 January 2018 (UTC)[reply]

Oh yeah. It's happening all round. And they also invented a new word, "retpoline".
I guess it's better than the retronym FUCKWIT they considered on LKML, before settling on KPTI... :D Decoy (talk) 17:55, 4 January 2018 (UTC)[reply]
And GCC apparently has patches too... Legoktm (talk) 09:32, 5 January 2018 (UTC)[reply]

javascript leverating spectre

[edit]

there are multiple sources saying javascript can leverage spectre. chrome isolites websites into its own operating system process, while firefox does it only for a certain number. i find it hard to understand from the article how high precision timers and site isolation are related or not to prevent the problem. anyone could rephrase it in a way easier to understand? --ThurnerRupert (talk) 08:14, 6 January 2018 (UTC)[reply]

Isolating it to a process is not a deal-breaker. Think about it: any code that is executed on the system is by nature isolated to its own process. In the same way, this exploit running in javascript has access to the full memory mappings provided to the parent browser process -- or the same external access as running a compiled C executable on the system would have.
I went ahead and added a sub-section explaining how the proof of concept worked around the issues of being interpreted and not having direct access to cache-line flushing, etc. Can be found here: http://en.wiki.x.io/wiki/Spectre_(security_vulnerability)#Exploiting_via_interpreted_language_(javascript) I hope this helps!
-- Tim — Preceding unsigned comment added by 73.200.101.158 (talk) 22:15, 8 February 2018 (UTC)[reply]

thanks a lot, really helpful! jann horn reported that he developed a spectre_v1 attack against the kernels JIT engine. does this mean JIT can be used to exploit v1 only, or it does not matter, can be meltdown/v2 as well? --ThurnerRupert (talk) 05:56, 10 February 2018 (UTC)[reply]

"Detailed explanation"

[edit]

What little is cited in this section seems to be attributed to a primary source. Please review the relevant sourcing policy and cite these materials with reliable secondary sources.

I'm inclined to remove material in this section that is not appropriately sourced soon. As it stands, it looks like that would mean most or all of this section has to go. --causa sui (talk) 21:01, 8 January 2018 (UTC)[reply]

It is highly technical too, even if it is sourced, please explain away from technical as possible (even by defining relevant information as the Meltdown page has 134.186.234.108 (talk) —Preceding undated comment added 22:48, 9 January 2018 (UTC)[reply]
I don't agree. The section is very important. I have put it back in. It's ridiculous to say that we can't put this information in because it comes from the original paper by the researchers! Where else should it come from? Eric Kvaalen (talk) 08:14, 25 January 2018 (UTC)[reply]
The original explanation I gave was a rushed job, when the events were still unfolding. I agree it isn't sourced too well against the standing guidelines, but at the time I used what little data was available. I stand by my explanation, so that now that multiple secondary sources are finally available, I'd suggest the explanation ought to be sourced better after the fact. Not just cut out. Obviously the description should also be refined, given newer, better informed analysis online. Decoy (talk) 00:18, 6 February 2018 (UTC)[reply]
As for technicality, I don't believe there is any way around it on a topic such as this. Spectre and Meltdown really do touch rather a deep level of processor microarchitecture. At a level 20 years of microprocessor engineering didn't see coming. You cannot exactly explain a bug at level using common language, no more than you can explain hard mathematics using layman's terms. My wording can and shoudl be improved, of course, but I fear a section termed "Detailed explanation" will necessarily remain rather technical. At least if it tries to be precise in its description of the underlying problem we're talking about. Decoy (talk) 00:26, 6 February 2018 (UTC)[reply]

iOS mitigation

[edit]

https://melv1n.com/iphone-performance-benchmarks-after-spectre-update/ — Preceding unsigned comment added by 83.237.222.89 (talk) 19:00, 12 January 2018 (UTC)[reply]

I don’t think this is a particularly controversial issue. We should simply report RS. My problem in some related articles has been WP:RECENTISM, and possibly some bias. This article appears to have mostly avoided such issues, is balanced, and has avoided very long talk debates. OTOH, I’m seeing problems in the AMD and Intel articles related to this issue. IMO, these articles (possibly ARM and others) should be in sync with this (and Meltdown (security vulnerability) articles where applicable). I’d appreciate efforts to keep these articles, on this particular subject area, in sync. O3000 (talk) 01:29, 14 January 2018 (UTC)[reply]

nonsense claims

[edit]

This article contains lots of nonsense claims. Here is one crazy wrong claim

A large portion of the current mid-range Android handsets use the Cortex-A53 or Cortex-A55 in an octa-core arrangement and are not affected by either the Meltdown or Spectre vulnerability as they do not perform out-of-order execution.

Spectre does not require execution to be out of order! A necessary requirement is that the processor speculatively loads cache lines. THAT'S IT. A simple branch predictor that speculatively executes code.

Please fix this garbage article. --64.121.146.209 (talk) 21:36, 26 January 2018 (UTC)[reply]

I've removed this text from the article because the sources look iffy to me. However, I think you'll generally get a better response with less dramatic language. Just a friendly suggestion. O3000 (talk) 21:51, 26 January 2018 (UTC)[reply]
I agree with the OP. The article is simply terrible, full of inacurracies, confusing, misleading, and outdated now. I don't see how it can be easily fixed. I can't go through the errors one by one, and then argue each one of them separately here with a bunch of people. I think such an approach wouldn't make much difference to the status quo.
I don't know what is a solution or procedure on Wikipedia for this kind of problems. Z80Spectrum (talk) 05:35, 10 February 2024 (UTC)[reply]
Can someone just stick that "This article is in need of an expert" tag to the top everywhere, preferebly both on this talk page and on the top of the article. Z80Spectrum (talk) 05:41, 10 February 2024 (UTC)[reply]
Banner added. I'll also add this to my review project. ~Kvng (talk) 16:38, 12 February 2024 (UTC)[reply]

Need better Spectre v1 and v2 descriptions

[edit]

And why one of them can be fixed, while the other one is almost impossible to fix. Artem-S-Tashkinov (talk) 13:09, 29 January 2018 (UTC)[reply]

Techniques have now been demonstrated to overcome the need for high precision timers.

[edit]

I would like to add a description of a technique that overcomes the need for high precision times. There is a proof of concept, it is not a fiction, and there is a description of how it works. I think this is news, and that it changes the context of some of the other information on the page too, but I am not proposing to modify any existing content yet. Just weeks ago Firefox moved to 20usec timer precision, and that is now known to in inadequate. Chromium have landed 100usec plus fuzz and commented in the source code that that would prevent attacks just weeks ago. This is moving fast. I am the author of the technique. — Preceding unsigned comment added by WebLLL (talkcontribs) 15:49, 9 February 2018 (UTC)[reply]

This is the proposed addition to the page, for a start. I think more will be necessary this new information casts some of the current content in a different light.

Copy of proposed edit to the main article:


The self claimed Spectre Cascade technique[1] argues that high precision timers are not required for a Spectra out of bounds attack and that there is no safe timer mitigation threshold, and includes a proof of concept to verify the claim. The technique describes a program loop that has a measurable run time difference depending on the effect on the cache that might be leaked in a speculative code path. The technique claims to not require cache flush instructions or barrier instructions and that this makes it well suited to use on the web. The included proof of concept requires a congruent cache set to be found but claims that there are some published methods for discovering these. The claim describes the speculative path loading from either addresses in the same cache set that the miss predicted branches load from, and from one of two subsets to either load from or evict the branch load subset based on the leaked data obtained in the speculative path. It is claimed that this creates a feedback loop with two distinct states: one state evicting which causes delayed loads and which runs slowly; and the other reinforcing a cache subset and running quickly. It is claimed that increasing the number of iterations can overcome timer precision reductions. It is also claimed that the technique implements self supporting cache eviction to drive speculation and that the technique is far more efficient than attempting to accumulate a large cache timing effect in the cache.

Could people please offer more specific help than simply continually reverting the addition. If I may attempt to address some of the issues raised in the reverts. I am the author of the technique and the publication, it is a primary publication. I am not promoting myself or family or a business, my name appears nowhere, the website has no advertising. I claim to have expertise in this area, so naturally my contribution is in a narrow area. The addition is largely factual, and it describes additions to the understanding in this area, and the publication includes a proof of concept allowing other people to verify the claims, and it does cast other information on the pages in a different light. This is an area of knowledge that is moving fast, and an area where it appears that knowledge is not being shared publicly, and if people such as myself can not meet an acceptable standard by such disclosures and publications then we simply will not be part of the conversation, and it might be that people who can comment are compelled not to, so I plead that you take these circumstances into account. The technique has been disclosed publicly now and there is a proof of concept and I plead that it be accepted as a fact. Compared with some other information on this page I believe it is of higher quality, coming for the author and with proof. Helpful suggestions are welcomed. — Preceding unsigned comment added by WebLLL (talkcontribs) 17:27, 9 February 2018‎ (UTC)[reply]

@WebLLL: Thank you very much for first adding your proposed edit to this talk-page for discussion - and for WP:CONSENSUS from other Editors - Comments Welcome from other Editors on adding the proposed edit (copied above) to the "Spectre (security vulnerability)" main article - Thanks again for adding the proposed edit to the talk-page for discussion - and - Enjoy! :) Drbogdan (talk) 02:29, 10 February 2018 (UTC)[reply]

References

  1. ^ WebLLL (9 February 2018). "Spectre Cascade". WebLLL.org. Retrieved 9 February 2018.
@WebLLL: you mind adding what can / should be done to counter such an attack? the "usual" operating system patches in place e.g. for linux 4.15.2 upwards help? --ThurnerRupert (talk) 05:59, 10 February 2018 (UTC)[reply]
@ThurnerRupert: The proposed additions to the page do not address what can and should be done for mitigation, it just adds the knowledge that high precision timers are not needed for the attack and that there appears to be no safe timer mitigation. The other side of mitigation is to block infiltration by appropriate code generation, and would you like me to add a quick note saying that? There are no kernel patches that I am aware of that can address Spectre attacks in user code such as in web browsers. WebLLL (talk) 06:30, 10 February 2018 (UTC)[reply]

@Bart Jacobs (Leuven), Causa sui, Decoy, Legoktm, Mardus, Matthiaspaul, Objective3000, Rakerman, Stefan2904, and Widefox: and others - If interested, and if possible, please help evaluate whether this proposed edit (see copy above) should be added (or should not be added) to the main article - tia - and - Enjoy! :) Drbogdan (talk) 14:39, 10 February 2018 (UTC)[reply]

The proposed para needs copyediting, clarification, and possibly splitting. I'd also like a visual of this (an image, preferably an animated GIF). -Mardus /talk 14:52, 10 February 2018 (UTC)[reply]
User:WebLLL User:Drbogdan. That's a primary, self-published, non independent source from a conflicted editor with a username violation. No, until there's a secondary source this should not be added, and is WP:OR WP:NOT#NEWS WP:RECENTISM. Widefox; talk 15:18, 10 February 2018 (UTC)[reply]
It sounds interesting. But, I have to agree with all of Widefox’s guideline cites. We must have a secondary source and it must establish a connection to this or some other article. O3000 (talk) 15:56, 10 February 2018 (UTC)[reply]
The authors account appears to have been blocked based on the comments of User:Widefox, on the basis that the user name is self promoting. The blocking message included a request to create a new account and that has been done and the new user name chosen somewhat randomly. In defense, while the user name WebLLL was also the name of the authors website that seems a trivial complaint and I would also draw attention to the fact that the user name Widefox is also the name of a web browser that may well be connected with the user User:Widefox, that the complainant's user name may well have been promoting the complainant's product. The Spectre vulnerability may well embarrass the Widefox product because web browsers are badly affected, and the knowledge being proposed to be added embarrasses claims that web browser timer mitigation protects against these attacks. People making technical comments here should be capable of running the proof of concept and verifying the claim and then seconding the source if they wish to be helpful. The circumstances of this knowledge are exceptional and I plead to those with authority here that it is also an apparent conflict of interest to block the wider disclosure of this knowledge and to be dismissive of its credibility because there are many organisations and people who may be embarrassed by Spectre disclosures and wish to delay the wider disclosure until that have had time to rework the own products, so the circumstances are exceptional. So I plead that proof of concepts, and the failure of people to offer a refutation to easily reproducible proofs, should tip the scales towards those claiming such knowledge should be added even given the other apparent procedural variations from the norm. If someone, anyone, would step forward to help and second the source or write an alternative it would be appreciated. Hkh91Sb (talk) 20:54, 10 February 2018 (UTC)[reply]
Assuming this is your first post, you’re off to a bad start. First, please read WP:aspersions. You should not cast aspersions against other editors. Secondly, your statement: People making technical comments here should be capable of running the proof of concept and verifying the claim.... is way off base. This is not a research organization. In fact, original research is not allowed. Editors do not have to have deep technical knowledge to edit a tech article. This is because we rely on secondary sources, not our own knowledge. Please read WP:IRS. Thirdly, no one here has been dismissive of the content. Rather, you have been dismissive of Widefox's cite of guidelines with a suggestion of conflict of interest. You are welcome to edit here. But, please realize an encyclopedia must have guidelines. O3000 (talk) 21:14, 10 February 2018 (UTC)[reply]
O3000That seem a little harsh, I have been honest and open and are acting in good faith. Could you point to any rule that soliciting for someone else in the community (and some editors here might have deep technical knowledge) to second my primary source to overcome the apparent concerns about a conflict of interest is inappropriate? Can you offer any helpful suggestion on how I can overcome the concerns or are you saying that knowledge sources from people such as myself is effectively excluded form Wikepedia? Hkh91Sb (talk) 22:28, 10 February 2018 (UTC)[reply]
I provided sources of info for you. In particular, read WP:IRS and WP:OR. We are not an academic journal. We don't publish original research. We use reliable sources, in particular, preferably sources. In this manner, we can ensure verifiability WP:V. O3000 (talk) 22:39, 10 February 2018 (UTC)[reply]
O3000 Thank you. A 'Connected contributor' header has been added to the proposed addition and can that overcome the conflict of interest concern or can you help with getting that right? Even then it does not appear to read correctly to me, I am not really connected to the subject which is purely technical, but I am happy to add some disclaimer if that overcomes any concern. Regarding WP:IRS there is a proof of concept in the source, and all I can add is that it takes expertise, other than that again I ask someone with expertise to consider the reliability of the source (this is not a demand that editors have that expertise). Regarding WP:OR the proposal does not publish original research here, that is published in the linked page and the proof of concept on that page demonstrates its reliability. Hkh91Sb (talk) 23:07, 10 February 2018 (UTC)[reply]
That's a warning template that usually ends in removal. There must be secondary sourcing for this type of addition. It cannot be added. O3000 (talk) 23:15, 10 February 2018 (UTC)[reply]
O3000 Thank you, but that is very disappointing. If nothing else the editors now have a refutation that casts the current content in doubt, makes in clear to any expert that that content is not reliable and perhaps there is at least enough credibility in the single source that it would be appropriate to ask the sources of the existing content if they have withheld information that casts the current content as inaccurate. I can not disclose more without breaking confidence. Hkh91Sb (talk) 23:45, 10 February 2018 (UTC)[reply]
In an encyclopedia, verifiability is more important than "truth" and speed. O3000 (talk) 00:00, 11 February 2018 (UTC)[reply]
Hkh91Sb there's at least three problems with that conspiracy theory:
1. Someone else User:Lourdes beat me to reporting the User:WebLLL accountname violation [1] which I seconded [2]. Do they have a COI too? Frustrating when WP's stuff works correctly huh, and there's WP:CONSENSUS. Maybe they own Lourdes? I don't know but I wish they did :)
2. An admin would have to agree to it, so the person that blocked that account was User:Edgar181 not either of us who reported a violation as we can't block anyone
3. If you really believe that I have a WP:COI here then please take up that allegation at the right venue which is not here but follow the instructions at WP:COIN. I can tell you that I clearly haven't declared one here or ever per WP:COI / WP:DISCLOSE. No I don't have one.
You may want to consider Don't shoot yourself in the foot as clearly your genuine concern may be seen as something else.
Oh, O3000 I forgot to add WP:NOT#PROMO, and after this message above, clearly WP:NOTHERE and WP:BATTLEGROUND. Widefox; talk 21:38, 10 February 2018 (UTC)[reply]
The Wikipedia policies do allow WP:SELFPUB and WP:SELFCITE so long as this follows the policies for these, and I plead that the proposed addition does follow these policies, or plead for help in amending the proposal to meet these policies. To claim that self publishing is self evidently a WP:COI would be to disallow WP:SELFPUB which is clearly not the case. I have no conflict of interest to declare, and none has been raised apart from claims it promotes my website. Thus it does not appear to be hopeless to have this addition added to the article, and not inappropriate to seek this. So WP:SELFPUB asks that "the material is neither unduly self-serving nor an exceptional claim" and I plead that the proposed addition is not self-serving and I have weakened the wording if that helps and it does cite a proof of concept; it also asks that "it does not involve claims about third parties" and no claims about third parties are made; it also asks that "it does not involve claims about events not directly related to the source" and the proposal only summaries the source; it also asks that "there is no reasonable doubt as to its authenticity" and no reason to doubt authenticity has been raised and I can probably address any doubts if they are raised; it also asks that "the article is not based primarily on such sources" and the Spectre article is not based heavily on this self cited source and the addition to the article is just one small additional piece of knowledge. Thus I plead that the proposed addition meets all the requirements for WP:SELFPUB and plead that it not be rejected as a violation of that policy. In any case I have modified the proposal to weaken it to just a note that the self claim was made, and that is evidently true. The policies for WP:SELFCITE ask that it be relevant and not excessive and it is relevant and not excessive, and also asks that it be written in the third person and an attempt to do so have been made and help is welcomed in addressing that. Thus I plead for people to re-cast their objections clearly in this light and only after considering if helpful suggestions could remedy any defects. Hkh91Sb (talk) 02:54, 11 February 2018 (UTC)[reply]
Hkh91Sb Unless there are reliable secondary sources it's time to back away from the dead horse as this disruption has gone on long enough now. Consensus is not to include this until there are secondary sources, so stop this WP:ADVOCACY / WP:NOT#PROMO from a WP:COI WP:SPA account immediately per WP:IDHT. Widefox; talk 11:16, 11 February 2018 (UTC)[reply]
Some more public support for the knowledge that the Spectre vulnerability does not depend on precision timers, at least not on the precision timers that were firstly disabled or had they precision reduced, comes from the recently landed Firefox patch that reduces timer precision resolution to 2ms from 20us "Bug 1435296 Bump the default timer precision resolution to 2ms". 12 February 2018. and that is a very large reduction in precision. Does that qualify as a reliable secondary sources? Hkh91Sb (talk) 01:28, 13 February 2018 (UTC)[reply]

cpus without speculation

[edit]

just as a side note, linux now started to contain (intel) CPUs without speculation which are exempted from countermeasures: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.15.2&id=bcfd19e90a7dfda456da1d59c22fba277e5c2237 --ThurnerRupert (talk) 06:02, 10 February 2018 (UTC)[reply]

Reversion of AMD text on Spectre

[edit]

@Denniss:, I have the read numerous articles and believe the text that you modified was an accurate portrayal of RS. I'm sure you know that calling RS bullshit and adding your own conclusions is not how we edit articles. AMD's initial statement, which roiled the tech market, was inaccurate and was later dramatically changed. O3000 (talk) 12:41, 18 March 2018 (UTC)[reply]

Your "reliable sources" read like AMD denied their CPU are affected by Spectre. This is completely wrong as they were 100% clear on that in their original statement. Many sites seem to have taken the "near zero risk" out of context, applying it to both Spectre 1 and 2 whereas it has always been a statement regarding Spectre 2. See AMDs original statement--Denniss (talk) 13:03, 18 March 2018 (UTC)[reply]
They essentially denied it. Their stock shot up in the market as Intel's stock sank with articles saying how they would take large advantage of Intel since this was an Intel embarrassment and AMD chips were essentially unaffected. On their second statement, RS used words like "reversed". The simple fact is that their first statement caused misleading headlines that were corrected after their second statement, along with a market correction. It is important to note that their first statement was misleading. And, you should obtain consensus before altering this text, as otherwise you are simply edit-warring. O3000 (talk) 13:14, 18 March 2018 (UTC)[reply]
Where did they deny it? Please post a "reliable" primary source where they said this! In the statement they released (and I linked to with an archived copy of the original) they fully acknowledged Spectre v1, noted "near Zero risk" for v2 and zero risk for Meltdown. Or do you mix this up with Meltdown which does not apply to AMD? Intel stocks were falling after Meltdown but seem to have recovered quickly.--Denniss (talk) 13:23, 18 March 2018 (UTC)[reply]
EDIT: Please note in the initial hurry to set up articles about the issues many sites seem to have merged Meltdown and both Spectre variants (or just both Spectres) together as the initial informations were somewhat confusing. We have to report neutral facts not based on errors made by other sites. --Denniss (talk) 13:30, 18 March 2018 (UTC)[reply]
I didn't mix up anything and this is unrelated to Meltdown. Intel acknowledged a problem. AMD claimed "near zero risk". There is zero evidence that the risk was less for AMD as the exploit is very difficult to build for both. Their first statement suggested that they were safe compared to Intel. Their second statement dispelled this incorrect suggestion. Hence, the market correction. Ignoring this is a whitewash and ignores the substantial RS reporting. O3000 (talk) 13:35, 18 March 2018 (UTC)[reply]
AMD never stated they were unaffected by Spectre, "near zero risk" was for Spectre 2 and is still correct as of today. These are facts. Please compare Intels initial press release [3] with that from AMD, Intels is is in contrast to AMDs release where AMD made clear how/where they are affected and where not. BTW Intels release does not separate Meltdown from Spectre so they could deny an "unique to Intel" issue. I'm still waiting four your source where AMD claims it's not affected by Spectre or even has near zero risk for spectre. You won't find it as AMD never made such a claim, such a wrong claim would result in legal problems especially with the SEC. --Denniss (talk) 14:43, 18 March 2018 (UTC)[reply]
AMD said "Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time." This was about all vaiants. Then they backtracked.[4],[5],[6],[7],[8],[9],[10] O3000 (talk) 20:03, 18 March 2018 (UTC)[reply]
That's not true, they never said this covering Meltdown and both Spectres. There are some claims about this info originating from an unnamed spokeperson but without knowing the exact source one cannot verify it's an official statement. I really hope CNBC (where this claim seems to originate from) and others did not create this info on their own based on a Linux commit from AMD's Tom Lendacky where he requested to disable KPTI (Meldown workaround) for AMD CPUs in Linux [11]. Note that the original report by The Register - who got all this rolling weeks before the intended publication date - uses exactly this linux kernel mailing list comment to state AMD is not affected while we now all know this is just Meltdown [12].--Denniss (talk) 20:53, 18 March 2018 (UTC)[reply]
This is heavily covered by RS. We follow RS, not what you believe is the "truth". The Register is a questionable source. It certainly does not trump Forbes, CNN, and CNBC. You are now edit-warring on two articles. O3000 (talk) 21:01, 18 March 2018 (UTC)[reply]
Register is unreliable indeed but they jumped the wagon and forced all others to release the vulnerability information far earlier than intended. Astonishing you don't know this. CNBC report is insofar unreliable as they do not city the alledged AMD information to one person as no one knows who this is and whether he/she had the authority to issue such a statement. There's only one official statement/press release from AMD regarding Meltdown/Spectre and that is a reliable fact. If a wrong person issues such an information it may cause a lot of anger/trouble around customers, this also happened with AMD and their first Adrenalin driver release for which were many problems with older games were reported but a support member of the AMD customer forum said it's not an issue and not to be fixed (he didn't have authority to say so and didn't even bother to inform the official AMD driver team). This caused a lot of media coverage until the head of the AMD driver team jumped in to acknowledge a driver problem that is to be fixed (AFAIR he wasn't even contacted by media but learned about the issue from press coverage).--Denniss (talk) 07:17, 19 March 2018 (UTC)[reply]
I did know this and am tiring of your snide remarks. We use reliable secondary sources. I provided several. Primary sources are rarely used when secondary sources are available. AMD made an incorrect statement that caused turbulence in the markets. I’m not particularly interested in what internal machinations were behind this statement. The statement was published on the AMD site as an official response. They later backtracked, making a second statement. This is widely covered in RS and is as was described in the articles before you edit-warred them out. The article is now missing this information. O3000 (talk) 11:35, 19 March 2018 (UTC)[reply]
Please provide a link to this statement from AMD on their website. --Denniss (talk) 14:38, 19 March 2018 (UTC)[reply]
They posted it on Jan 3 and updated it on Jan 11. Then deleted the original. It is no longer there. We don't use primary sources, or what you know to be the "truth", anyhow. We use reliable secondary sources, which are abundant. O3000 (talk) 14:45, 19 March 2018 (UTC)[reply]
See link in my first answer which goes to an archived page (Jan 4). There's nothing deleted from the initial release. --Denniss (talk) 14:52, 19 March 2018 (UTC)[reply]
I read in on Jan 3. We don’t see it the same way. That’s one of the reasons we use secondary sources. Our opinions are not reliable sources. O3000 (talk) 14:59, 19 March 2018 (UTC)[reply]

Objective3000 and Denniss If AMD's statements on the exposure shifted between Jan 3rd and 11th can easily be compared on the secondary wayback machine [13] and [14]. No need to rely on anyone's memory. And O3000, as we discussed previously, there are secondary source that also support AMD's clarification not being a "backtrack" too. [15][16][17] As I stated then: I believe we should be clear in what AMD said, and what was said about AMD. I believe this may be key to keeping the language NPOV.Dbsseven (talk) 16:42, 19 March 2018 (UTC)[reply]

We have been over this. Two of the sources you provided support the text that Dennis removed. The third is Twitter. The article now completely ignores the change in AMD’s position, as widely reported in RS. As I said before, let us stay with reliable sources and not add our own interpretations. O3000 (talk) 16:49, 19 March 2018 (UTC)[reply]
I disagree with your position that the cites "support the text that Dennis removed" as both sources state "AMD said" there was no change in position. (And the third source is am expert in the field,[18][19][20] so I would not disregard the source by the publication medium.)
However, if we're going to focus on reliable secondary source, the same standards for citations should apply to all manufacturers equally, right? (The proceeding Intel sentence only references the company's response, not outside sources evaluation of their response.) Given this, I propose: AMD responded with a report on its exposure to the Spectre flaws, and later issued updates to address them. (Simple, to the point, avoids interpretations.) Dbsseven (talk) 17:35, 19 March 2018 (UTC)[reply]
Even your refs specifically state that the position changed. They state this outright. Dozens of articles from RS state this. As for Twitter, I won't even read it. Twitter is not RS. As for another sentence about another manufacturer, that is OTHERSTUFF. If you want to start a thread about that, do so. It has nothing to do with this thread and suggests bias on your part. We are not here to go tit for tat. We construct based on RS. Once again, we use reliable secondary sources, and they all say there was a change in position. It sounds like you are in denial for some reason. Why do you want us to omit what so many, many actual RS state? O3000 (talk) 22:04, 19 March 2018 (UTC)[reply]
Objective3000 As has been said before, please no personal attacks. If you'd like to discuss facts that's fine, but "you are in denial" and "bias on your part" is inappropriate. Dbsseven (talk) 18:09, 20 March 2018 (UTC)[reply]
As for RS, I have no problem including other sources interpretations of AMD's position, but they should be described as such if there other sources (and the manufacturer) state otherwise. Again: what AMD said, versus what was said about AMD. (A single editor refusing to read twitter does not automatically make it an unreliable source. This is for consensus to decide. IMO Twitter is not the author, but the publication medium.) Dbsseven (talk) 18:09, 20 March 2018 (UTC)[reply]
Twitter is the secondary source. Twitter is not RS, and the opinions expressed by this guy on Twitter are useless. It most certainly does not approach CNBC, Forbes and CNN. I have supplied several reliable secondary sources. The removal by edit-warring is against WP policies. O3000 (talk) 18:12, 20 March 2018 (UTC)[reply]
I would suggest reviewing WP:SPS "Self-published expert sources may be considered reliable when produced by an established expert on the subject matter, whose work in the relevant field has previously been published by reliable third-party publications" (And the author writes for Marketwatch, one of the sources you are citing.) Dbsseven (talk) 18:24, 20 March 2018 (UTC)[reply]
You have one primary source that is a two sentence tweet starting with "It seems" by some guy not in WP, suggesting some nastiness by the media. Do you honestly think that is a source that should be used by an encyclopedia? Would you like to take this to RS/N? Or, accept the quite large number of reliable, secondary sources as per Wikipedia guidelines? O3000 (talk) 19:10, 20 March 2018 (UTC)[reply]
The "it seems" refers to other published reports. The statement about AMD's position is without equivocation. (As for "nastiness" this is WP:OR as it is not in the cite.) So yes, I do honestly think an expert commenting in a tweet on his area of expertise should be used in an encyclopedia.
I believe the perspective should be balanced (WP:BALANCE) as not all RS agree, balancing their reliability and expertise. This means not excluding either set of reliable sources. I believe compromise/consensus language can be found around this and propose: "AMD responded with a report on its exposure to the Spectre flaws, and later issued updates to address them. Some reports described the later announcement of mitigations as a reversal of AMD initial "near zero" exposure to Spectre variant 2, thought this was disputed by AMD and others." I am happy to go to RS/N to discuss this. Dbsseven (talk) 17:38, 21 March 2018 (UTC)[reply]
ps: Even your first source reiterates AMD's position: "AMD said...there's been no change to its position on the susceptibility to the second variant of Spectre for its chips and only that it's rolling out optional updates to further contain the threat"[21] Dbsseven (talk) 17:44, 21 March 2018 (UTC)[reply]
Oh and the reference to Intel's text as WP:OTHERSTUFF is off base, as Intel is central to your argument for inclusion of this material. WP:OTHERSTUFF is grounds for notability of an article. I don't think the intent is to be applied selectively, line-by-line within an article. Dbsseven (talk) 17:51, 21 March 2018 (UTC)[reply]
If you want to add a lie by AMD from an RS, you can do so. But, the text that was in the article is widely sourced to reliable secondary sources and was edit-warred out of the article against guidelines. In no way does that tweet meet WP:IRS. O3000 (talk) 18:02, 21 March 2018 (UTC)[reply]
You may personally disagree with citing a tweet, but it falls exactly within WP:SPS guidelines: "Self-published expert sources may be considered reliable when produced by an established expert on the subject matter, whose work in the relevant field has previously been published by reliable third-party publications" Given this (and it is not the only cite) do you have specific objections with the prose I suggested? If not, I will add it with the cites we have discussed. Dbsseven (talk) 18:11, 21 March 2018 (UTC)[reply]
I don't know what prose you mean. The established text is correct, widely cited,and should be restored. O3000 (talk) 18:33, 21 March 2018 (UTC)[reply]
Okay, then here is another try, incorporating the current prose: "AMD stated that it was vulnerable to Spectre variant one, while variant 2 posed "near zero risk of exploitation" due to differences in AMD architecture. When AMD subsequently announced a firmware mitigation to Spectre variant 2, it was described by some as a reversal, thought this was disputed by AMD and others." I understand you are fond of the current prose. But clearly other editors disagree, so a new consensus should be found. (WP:CONSENSUSCANCHANGE) Dbsseven (talk) 18:50, 21 March 2018 (UTC)[reply]
Taken to RS/N. Wikipedia:Reliable_sources/Noticeboard#Tweet_as_an_RS O3000 (talk) 18:54, 21 March 2018 (UTC)[reply]

Wording in first-person cut-and-pasted

[edit]

There is a sentence which reads, "There are several automatic cache eviction policies which the CPU may choose, and we rely on being able to force that eviction for the exploit to work." That appears to have been extracted from the white paper. The problem with the text here is that the use of the word "we" and the tone of the message is first-person, lacking a source being quoted. The sentence really should be altered to be a generic explanation of what is being relied upon, the use of the word "we" should be reworked. AlsoMostlyHarmless (talk) 15:46, 30 March 2018 (UTC)[reply]

Agree. I don't have the expertise to fix up this article, but it could use some copyedits. Note also the inexplicable brackets in the sentence, "... in this case, lower, microarchitecture-level optimizations to code execution [can] leak information not essential to the correctness of normal program execution." And even more also, this sentence is highly confusing: "Atom CPUs used on the D270 and 1001PXD are known to be vulnerable but as these are now old machines using the VT-64x and N455 CPU it is less likely to be a problem." I assume it's meaningful to Atom experts, but I am not one. IAmNitpicking (talk) 15:45, 30 October 2019 (UTC)[reply]

Spectre Next Generation

[edit]

https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html — Preceding unsigned comment added by 90.154.67.41 (talk) 00:19, 4 May 2018 (UTC)[reply]

Doesn't read like an WP:RS and is a bit dated. I don't see other sources along this line. O3000 (talk) 00:24, 4 May 2018 (UTC)[reply]
Aah, it's now popping up elsewhere. O3000 (talk) 11:06, 4 May 2018 (UTC)[reply]
Huh? Although dumbed down in recent years, c't (magazin für computertechnik) is still a highly reliable source. They don't make up things. --Matthiaspaul (talk) 11:02, 5 May 2018 (UTC)[reply]

On what grounds is Variant 4 being called Spectre?

[edit]

I don't see justification in most sources that Variant 4 is properly called Spectre. I have added 3a and 4 to the mitigations table here - the specific implementations in Windows are not known yet but we do know there will be firmware fixes. If we are just going to lump all of these flaws together maybe there should be a single article Speculative execution security vulnerabilities to cover them (or at least the overall topic) since there is some duplication of material. I think we may be seeing a feedback loop from non-authoritative sites which think these subsequent variants are just different forms of Spectre when I think they fall under the larger umbrella of the proposed article. I have created an article Speculative Store Bypass under the premise that Spectre was the name of certain vulnerabilities when they were published and these new ones are not part of the same release. I think most discussion of variant 4 should be removed from this article lest we contrive a name for it. —DIYeditor (talk) 18:56, 22 May 2018 (UTC)[reply]

Matthiaspaul has named V3a and V4 in the mitigation table "Spectre-NG" but on whose authority is that? Are either of the two parties who discovered them calling them that? Do the CVEs or CERT notification use that term? It doesn't even seem to be present in the media covering this topic. I have only seen them referred to by the acronyms/abbreviations or whole name. What are they variants of? Not of Spectre but of the broader concept - speculative execution exploits. Otherwise V3 doesn't make sense - it's not Variant 3 of Spectre but of some other concept. —DIYeditor (talk) 22:50, 22 May 2018 (UTC)[reply]

While I'm not against splitting out contents from this article into others, I think your undiscussed moves were a bit too bold at this early stage - this easily creates redundancy and unnecessary overhead. Give it more time to develop and settle.
Regarding the name, Spectre is, apparently, the "handle" given to the broader concept. It was clear from the start that there would be more than only the two original Spectre variants.
The numbering goes back to Project Zero, who where among the discoverers of all but V3a. That's why the vulnerabilities are also called GPZ V1, V2, V3 and V4. (This does not apply to V3a, because it was discovered by ARM.) For the first two variants, this nicely lined up with Spectre, hence Spectre V1 and Spectre V2.
The provisional name "Spectre-NG" originates from c't, who where the first to report about these newer variants in public. They are also among those (many) who now call the new variants Spectre V3a and Spectre V4. (Following that logic, Meltdown should have been called Spectre V3 as well, but apparently wasn't.)
Yes, the scheme does not appear to be consistent, but there isn't much we can do about it.
--Matthiaspaul (talk) 09:04, 23 May 2018 (UTC)[reply]

Spectre-NG = Variant 3a and 4?

[edit]

I removed mention of Spectre-NG in the table at the end of the article since there's no evidence that the issues rumored in the german article (https://www.heise.de/ct/artikel/Exclusive-Spectre-NG-Multiple-new-Intel-CPU-flaws-revealed-several-serious-4040648.html) is related to Variant 3a and 4 for now. The german article doesn't mention at all what CVE number correspond to the 8 vulnerabilities detailed in it, so we can't actually be sure that Variant 3a and 4 are part Spectre-NG. — Preceding unsigned comment added by 174.91.223.158 (talk) 15:27, 11 June 2018 (UTC)[reply]

I restored the table and added a ref as it is very clear from the article that the two Variants 3a and 4 belong to the 8 Spectre-NG variants. --Matthiaspaul (talk) 20:24, 11 June 2018 (UTC)[reply]

This article is getting messy.

[edit]

This article is really getting messy since May 2018. It started to talk about other hardware side-channel vunerabilities like Variant 3a/4 and also LazyFP in the history and mitigation section. No mention of BranchScope and Meltdown/SpectrePrime though.

To keep the article understandable and focused on the main subject, this article should only talk about the Spectre vunerability as it was disclosed in January 2018. Other vulnerabilies should be discussed in their own article.

Or, perhaps a rename with redirects. Wouldn't it be easier for the reader to keep related issues together? O3000 (talk) 02:16, 17 June 2018 (UTC)[reply]

Inaccurate section

[edit]

This is not accurate:

Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.[1]

Spectre V1 is limited to the same process, V2 to other processes within the system, and Meltdown can also extract data from other VMs running under the same hypervisor. The source cited is outdated speculation. Reinistalk 20:07, 25 April 2019 (UTC)[reply]

References

  1. ^ Fox-Brewster, Thomas (2018-01-03). "Massive Intel Vulnerabilities Just Landed – And Every PC User On The Planet May Need To Update". Forbes. Forbes Media LLC. Archived from the original on 2018-01-03. Retrieved 2018-01-03. {{cite web}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

Mitigation

[edit]

The table in this section also exists here and here. I definitely think we should create a new article and merge these sections. Artem S. Tashkinov (talk) 11:30, 16 May 2019 (UTC)[reply]

SPARC?

[edit]

Does anybody have reliable info on situation of SPARC in regards to Spectre? AFAIK, Sparc V9 and newer are not affected by Meltdown (there older non-supported SPARC CPUs might be affectes, it is untested / unverified), but there is no reliable info about situation with Spectre. 81.6.34.246 (talk) 00:11, 26 January 2020 (UTC)[reply]

ARM: which CPUs was that again?

[edit]

Article now says, "Atom CPUs used on the D270 and 1001PXD are known to be vulnerable but as these are now old machines using the VT-64x and N455 CPU it is less likely to be a problem."

So CPUs based on D270 and 1001PXD are using VT-64x and N455 CPUs ... what? If they're VT_64x and N455, why is the sentence's subject saying they're "used on" those other unexplained designators? D270 (according to a quick web search) is a CPU itself, not something that has a CPU. I'm not expert enough to fix this, but it needs editing. IAmNitpicking (talk) 13:50, 16 July 2020 (UTC)[reply]

@IAmNitpicking: I just came here to say I'm deleting it because of the lack of source and lack of general soundness. I checked. ASUS Eee PC 1001PXD indeed comes with an Intel Atom N455. But Acer Aspire One D270 come with Intel Atom N2600 or N2800. And I have no idea what is VT-64x. I also studied both sources. There is absolutely nothing about D270, 1001PXD, VT-64x, or N455 in them. Waysidesc (talk) 07:58, 16 August 2020 (UTC)[reply]

The redirect Spectre (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 April 8 § Spectre (security vulnerability until a consensus is reached. Utopes (talk / cont) 01:09, 8 April 2024 (UTC)[reply]