This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all.
> Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.
> Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.
It then goes on with a straw man about performance impacts ("contrary to some reports").
And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.
I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for example). A new class of exploit was recently discovered, and these CPUs are vulnerable to this new exploit. But there was no bug in how these CPUs were implemented, and the only design flaw is that they failed to withstand a new class of exploit that was not known at the time they were designed.
(I don't have any information that could confirm/deny this, it's just how I interpret their verbiage).
I don't get the sense that they are trying to deceptively contradict only part of the previous statement.
It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.
My limited understanding is that the vulnerability is due to kernel memory protections not being applied during speculative execution, when the CPU is trying to second guess what the next instructions might be.
Unless you are in PR, any reasonable person would expect a CPU touted as having kernel memory protection to protect it under all circumstances. I'm sure that the people who wrote the speculative execution code would have included that protection had they thought of it, and all developers would class it's omission as a bug. So yes, this is yet another example of awful PR, trying to cover up a serious mistake with careful language that makes it seem not their fault.
My policy when I make a mistake is immediate disclosure, along with two commitments: to put the mistake right, and to amend processes to prevent similar mistakes in the future. It isn't clear how Intel can put this right, but perhaps a good discount on replacement parts might help. And they can certainly implement processes to catch such omissions in the future.
So this press release (particularly combined with reports of execs selling stock) are appalling. Intel have badly damaged their brand, and I'll never buy another Intel processor again.
I do not think the processor was designed to improperly unwind from speculative execution, such that the state after failed speculation is not identical to the state prior to speculation.
But yeah, this an old discussion, and a deep rabbit hole. There's many layers to consider bugs at. Implementation can differ from developer intention, developer intention can differ from group agreement, group agreement can differ from design document, design document can differ from product development intention, and product development intention can differ from communicated functionality.
I'm betting this would be implementation differing from developer intention, although I would consider (almost) all of the above to be bugs.
In the case of asymmetric competition, a company with vastly more resources might curate a list of undisclosed problems with competitors' products, for when a major event like this strikes, they can drag along the underdogs. The optics are different if 1) the dominant player can pretend it's "working together" with the other vendors, 2) the dominant player condescendingly points out mildly related issues in competitors' product, and 3) the name of the alternatives keeps getting linked in a "we're in the same boat" way.
I'm not suggesting this is the case here at all, as it's unlikely that Intel identified this precise issue with AMD long ago and haven't checked their own vulnerability (though there's always a chance that an issue is found by company A when analyzing the strengths and weaknesses of company B's products, which then turns out to apply for their own products too). But I wouldn't be surprised if somehow there were some loosely related AMD issues that came to light now, and it's impossible to tell if those would be current finds or older ones.
Given Intel's dominant position, they may come out ahead in P&L or gross margin terms even if it turns out to be a clearly Intel issue, as the perceived or real loss of performance may trigger an upgrade spree, sold unit counts inevitably dominated by Intel purchases.
AMD has just started to catch up in overall performance, and in the worst case bug impact to Intel, they may even get competitive single-threaded performance. Also, there has been speculation that Apple has been evaluating ARM processors for some future laptops, and a sudden drop of the baseline is an interesting turn of events.
While this in theory benefits the underdogs, financially Intel may well come out ahead due to their market hegemony.
I feel like a lot of really smart people are really naive about public relations.
PR exists to protect the company from the masses and the lawyers. We in the tech community should not waste time personalizing a response to pr communications. We are not the target market. It is the general public and politicians they are trying to persuade. If they ameliorate them, they win and can move on to the next fight.
They will play word games and fiddle with language. It is not worth responding to PR if you deeply understand the problem. You will only find problematic statements. You will never get satisfaction because satisfying the technical community is a fundamental error for anyone who knows what they are doing in public relations.
There are other venues for us. Patch notes and tech forums are worthy of your time.
> This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.
It looks like (some?) AMD processors might be affected as well: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."[1]
From what I can gather, one of the 3 issues found is Intel-only, very bad and very easy to exploit, and can be patched with a large performance hit.
Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon.
>...pointing out what the exploits cannot do (corrupt/modify/delete).
That statement is also untrue if you follow the implicit issue to it's inevitable exploitable end... Here is an equivalent statement of equal absurdity that intentionally neglects causality:
"Our door lock design contains a bug. The bug does not make stuff in your house disappear, does not manifest junkies into the vicinity, nor does it make property spontaneously combust."
> This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.
This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner?
I read this as Intel trying to imply that other vendors weren't probed and/or may not have this specific design vulnerability but can still be vulnerable...which I consider a vapid statement designed to distract the reader.
True, when a 0-day is found and disclosed it doesn't mean that there aren't other 0-days that haven't been found yet...but that has no relation to the significance of the newly disclosed vulnerability.
I judge this statement even more harshly because the flaw is so serious it's under embargo until OS vendors can try to protect users. Additionally, AMD seems to have said their processors are not vulnerable (https://lkml.org/lkml/2017/12/27/2)...
Edit: Some more information from Google Project Zero:
Edit 2: So it seems there are two slightly different attacks along this vector: Spectre and Meltdown. From the Google article(s) it seems Spectre affects Intel, AMD, ARM while Meltdown only affects Meltdown. This would appear to contradict the AMD statement regarding their processors not being affected.
I am not hardware guy and information is still coming out...but I am judging this Intel press release slightly less harshly (although it still reads pretty vapid).
The patch that was under question was related to a workaround for Meltdown, which makes AMD's note regarding the lack of necessity in agreement with the paper.
The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but I have only skimmed that paper so far.
I am going to go on a limb and speculate that Intel probably knows more about this problem than most. They are being quite specific that the issue affects multiple devices, and I doubt they are lying. And coincidentally several other reports (from Google, Wired and others) are indicating that this issue crosses CPU makers.
In that context, isn't you reply rather off the mark? If Intel's claim is correct, then being "defensive" seems entirely accurate given how many are foaming at the mouth at the prospect of some mortally wounded Intel.
"No problem here, move along, move along - you won't be able to modify/corrupt/delete that password, you can only read it in plain text. Nothing to see. Move on."
IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour.
Formally it is a bug in the spec, so indeed Intel products performs as designed. What is deceptive in the first part that the text does not tell that the design and specs were also done by Intel.
Intel should now recall the affected CPUs and ship new fixed CPUs without Intel "ME" for Management Engine, another well known open flaw.
In the end, hardware and software devs in the 1970s were right. Operating systems like MULTICS and computers like PDP-11 got it right. MULTICS supported 16 rings and has many advanced features that almost everyone forgot and never implemented in newer OS - shame on all of us!
Intel CPUs barely support more than 2.5 rings (if you count the VT that just blowed up). Also operating systems need to now focus on supporting more rings too. Just 2 rings aka kernel and usermode (and VT supervisor as third) is NOT enough in 2018.
> Intel believes these exploits do not have the potential to corrupt, modify or delete data.
Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase.
> Recent reports that these exploits are caused by a “bug” or a “flaw”
[Unprivileged] reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.
> any performance impacts are workload-dependent, and, for the average computer user, should not be significant
Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...
> However, Intel is making this statement today because of the current inaccurate media reports.
This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.
Yes it's designed in such a way that in a court of law they could claim they were announcing a bug, but most or many people reading it would come to the opposite conclusion. In other words it's deceptive.
> Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...
Has to be pointed out that they were correct. Public outrage forced them to change their tune, but their original summary was still on point. That said, it of course could majorly impact a select few.
> do not have the potential to corrupt, modify or delete data.
I believe the point of this sentence was simply to distinguish malicious read access (possible) from any modifying access (impossible).
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
I believe the second half of the sentence is far more important, i. e. the attempt to broaden the news story to include other chip vendors. The scare-quotes around "bug" may suggest that Intel thinks they correctly implemented Tomasulo’s algorithm, and any flaw would not be theirs–which actually goes well with the second half of the sentence.
The part on performance is probably correct: Consumers might not notice any hit in performance. Gaming seems not to be impacted, and CPUs tend to be under-utilised anyway.
Overall, I think this statement is obviously damage control, but there really isn't anything wrong with the content from a consumer user of an Intel CPU. Basically: don't freak out, install patches, stay tuned.
The tone is actually refreshingly to-the-point. At least they are not taking us on a voyage to Qualityland.
Your typical system has a rather large number of pieces that rely on that protection against read access in order to keep an attacker from obtaining information that would allow malicious corruption, modification, and deletion of data. Intel are being weaselly.
I’m with you that this is corporate-speak panicked PR damage containment at its finest, but reading from kernel memory is only a flaw if you aren’t the kernel. ;)
While I agree with most of the analysis, I don’t see any issue with the “operating as designed”. I mean, it is operating as designed. Really, I think they screwed up here. Instead of saying it’s an accident or a mistake, they are saying it’s the result of a careful and deliberate design choice.
- Cold naming AMD and ARM in the post, I'm certain not just to throw their names in the ring but also for SEO ranking and relationships.
- Failing to address the root cause, how it came to be and provide other technical references.
And let's not forget - Intel's CEO sold his stock.
--
* Note: "AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-int...
It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on.
> Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
> Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
It's interesting to note what it doesn't say – as it would seem to imply that for some workloads the performance impact will be significant.
“Workload dependent” clearly implies (despite the spin they are trying to put on it) that some users will be worse off than others. What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?
Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
> What isn’t my at all clear (to me) is what they mean by ”will be mitigated over time”. Are they implying that when we buy new professors (from them) there’ll be a hardware fix that won’t require the performance-sapping patch?
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.
> Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.
There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.
Because let's be honest: when I bought my XEON and i5 processors, performance wasn't the issue that made me pick Intel over AMD. PUH-LEASE. This is the worst kind of customer service malarky I have read in a while.
The "average" computer user may not notice the difference, but servers running Intel processors are used by businesses, hospitals, government, the military, cloud providers, and on and on. Often these organisations are thrashing this infrastructure to within an inch of its life.
Until fairly recently I was consulting and, no exaggeration, one of my former clients: if their SQL Server host takes a 15%, never mind a 30%, performance hit, they're screwed.
I personally have just been the prime mover in the procurement of a server costing £25k with a 3 year support contract, pretty carefully specced according to performance. And you're telling me I should be OK with that machine taking a 30% performance hit below what we specced? No way.
EDIT: Sorry, original version of last sentence was a bit out of order - the tone of that release got under my skin a bit.
> A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
Particularly bizarre considering the use of "believes". If Intel disbelieved that their own products are the best in any particular respect, that might actually warrant a press release on its own.
Lots of people being critical of this response. I think it's pretty good, and have been on the disclosing side of this equation many times.
Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're right but that's not a problem...
Short and sweet and has it all. If anything, it is a day late but monstrous organizations probably had a lot of bureaucracy to cut through.
People are so reactionary and quick to throw any company with a security issue under the bus, without ever having been on the other side of the table. The reality is issues happen to everyone and Intel wants to fix it.
I do agree that there are passages in this press release that are totally justified e.g. their calling attention to the fact that other processor vendors have probably been incorporating this flaw into their designs for a while. However, their seemingly innocent mentioning of AMD as being a vendor with which they are coordinating to resolve this issue appears to unfairly (and probably deliberately) implicate AMD in all of this. I feel this was an attempt to divert attention to their competitor even though their competitor's products don't suffer from this problem. I'm guessing their marketing department gave this a once over.
> their calling attention to the fact that many other processor vendors have been incorporating this flaw into their designs for while.
You have a source for this claim? Because besides for Intel's press release I can't find any evidence that other manurfacture's processors are vulnerable to this bug.
> Admits responsibility and says their current course of action
And specifically avoids mentioning that reading data is possible:
> Intel believes these exploits do not have the potential to corrupt, modify or delete data.
That's not taking responsibility. That's downplaying that the flaw exists.
A flaw their key competitor doesn't have, but they go on to mention several times just after they say things like " with many different vendors’ processors and operating systems — are susceptible to these exploits."
The entire thing has been written to be misleading. To pretend that the bug doesn't exist, and that AMD have it too, which is false.
> says their current course of action (working with key stakeholders)
"Working with key stakeholders" is not stating your course of action. At best, it is stating you are taking any action at all. I suppose that it is good that Intel has faith the stakeholders they are talking to are the important ones.
There are other issues Intel does not fix (backdoorable hardware outside of the control of the owner). This is part of Intel's image. So, there's that.
> Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Yes, many. Not your biggest competitor though, AMD. They're fine. And that may be the point you're trying to downplay here.
> Intel believes its products are the most secure in the world
Again, your biggest competitor, AMD, does not have this flaw. So precisely how is Intel the 'most secure in the world' if your biggest competitor is more secure than you?
The title of this post should be 'Intel PR Responds to Security Research Findings'.
It's always interesting when you see a damage control statement that basically boils down to "contrary to what you may have heard, <exactly the same caveats you've already heard>". It's a subtle kind of straw man, where you reassure your audience by listing the same mitigating facts they've already heard, but act as if those facts have been previously omitted.
I guess the goal is to produce the affect of reassurance when you don't actually have any substantive reassurance to offer. I wonder if this works, in general? My sense is that it always smells like bullshit, but I wouldn't necessarily recall instances where it didn't.
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.
There are suggestions it applies to Arm, as there is an arm64 patch for Linux although it hasnt been merged yet I don't think (although the performance hit for the fix might not be as bad).
If the general consensus that it's a timing attack related to speculative execution is correct, then Intel is correct to say that --- any CPU which does speculative execution in the aggressive manner that (most of --- AFAIK they still have some low-power non-OoO cores) Intels' do will be affected similarly.
Readit News
> Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.
> Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.
It then goes on with a straw man about performance impacts ("contrary to some reports").
And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.
And then as you say, they immediately mention AMD to imply that everyone has the issue, but they also avoid actually saying that.
Your excellent analysis of what they're really saying reminds me of user thaumaturgy's analysis of Adancing Our Amazing Bet[1].
[1] https://news.ycombinator.com/item?id=12793033
To add insult to this already cheap shot, it was flat out lies and AMD isn't vulnerable to all three variants.
This is just pathetic.
(I don't have any information that could confirm/deny this, it's just how I interpret their verbiage).
I don't get the sense that they are trying to deceptively contradict only part of the previous statement.
Unless you are in PR, any reasonable person would expect a CPU touted as having kernel memory protection to protect it under all circumstances. I'm sure that the people who wrote the speculative execution code would have included that protection had they thought of it, and all developers would class it's omission as a bug. So yes, this is yet another example of awful PR, trying to cover up a serious mistake with careful language that makes it seem not their fault.
My policy when I make a mistake is immediate disclosure, along with two commitments: to put the mistake right, and to amend processes to prevent similar mistakes in the future. It isn't clear how Intel can put this right, but perhaps a good discount on replacement parts might help. And they can certainly implement processes to catch such omissions in the future.
So this press release (particularly combined with reports of execs selling stock) are appalling. Intel have badly damaged their brand, and I'll never buy another Intel processor again.
But yeah, this an old discussion, and a deep rabbit hole. There's many layers to consider bugs at. Implementation can differ from developer intention, developer intention can differ from group agreement, group agreement can differ from design document, design document can differ from product development intention, and product development intention can differ from communicated functionality.
I'm betting this would be implementation differing from developer intention, although I would consider (almost) all of the above to be bugs.
I'm not suggesting this is the case here at all, as it's unlikely that Intel identified this precise issue with AMD long ago and haven't checked their own vulnerability (though there's always a chance that an issue is found by company A when analyzing the strengths and weaknesses of company B's products, which then turns out to apply for their own products too). But I wouldn't be surprised if somehow there were some loosely related AMD issues that came to light now, and it's impossible to tell if those would be current finds or older ones.
Given Intel's dominant position, they may come out ahead in P&L or gross margin terms even if it turns out to be a clearly Intel issue, as the perceived or real loss of performance may trigger an upgrade spree, sold unit counts inevitably dominated by Intel purchases.
AMD has just started to catch up in overall performance, and in the worst case bug impact to Intel, they may even get competitive single-threaded performance. Also, there has been speculation that Apple has been evaluating ARM processors for some future laptops, and a sudden drop of the baseline is an interesting turn of events.
While this in theory benefits the underdogs, financially Intel may well come out ahead due to their market hegemony.
PR exists to protect the company from the masses and the lawyers. We in the tech community should not waste time personalizing a response to pr communications. We are not the target market. It is the general public and politicians they are trying to persuade. If they ameliorate them, they win and can move on to the next fight.
They will play word games and fiddle with language. It is not worth responding to PR if you deeply understand the problem. You will only find problematic statements. You will never get satisfaction because satisfying the technical community is a fundamental error for anyone who knows what they are doing in public relations.
There are other venues for us. Patch notes and tech forums are worthy of your time.
It looks like (some?) AMD processors might be affected as well: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."[1]
[1] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon.
The third, I know nothing of.
That statement is also untrue if you follow the implicit issue to it's inevitable exploitable end... Here is an equivalent statement of equal absurdity that intentionally neglects causality:
"Our door lock design contains a bug. The bug does not make stuff in your house disappear, does not manifest junkies into the vicinity, nor does it make property spontaneously combust."
This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner?
I read this as Intel trying to imply that other vendors weren't probed and/or may not have this specific design vulnerability but can still be vulnerable...which I consider a vapid statement designed to distract the reader.
True, when a 0-day is found and disclosed it doesn't mean that there aren't other 0-days that haven't been found yet...but that has no relation to the significance of the newly disclosed vulnerability.
I judge this statement even more harshly because the flaw is so serious it's under embargo until OS vendors can try to protect users. Additionally, AMD seems to have said their processors are not vulnerable (https://lkml.org/lkml/2017/12/27/2)...
Edit: Some more information from Google Project Zero:
https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
So maybe AMD and ARM are vulnerable?
Edit 2: So it seems there are two slightly different attacks along this vector: Spectre and Meltdown. From the Google article(s) it seems Spectre affects Intel, AMD, ARM while Meltdown only affects Meltdown. This would appear to contradict the AMD statement regarding their processors not being affected.
I am not hardware guy and information is still coming out...but I am judging this Intel press release slightly less harshly (although it still reads pretty vapid).
The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but I have only skimmed that paper so far.
In that context, isn't you reply rather off the mark? If Intel's claim is correct, then being "defensive" seems entirely accurate given how many are foaming at the mouth at the prospect of some mortally wounded Intel.
https://www.wired.com/story/critical-intel-flaw-breaks-basic...
That’s the most concerning thing then
"No problem here, move along, move along - you won't be able to modify/corrupt/delete that password, you can only read it in plain text. Nothing to see. Move on."
IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour.
Deleted Comment
Unless you view a key or password... then use it to corrupt, modify or delete data.
In the end, hardware and software devs in the 1970s were right. Operating systems like MULTICS and computers like PDP-11 got it right. MULTICS supported 16 rings and has many advanced features that almost everyone forgot and never implemented in newer OS - shame on all of us!
Intel CPUs barely support more than 2.5 rings (if you count the VT that just blowed up). Also operating systems need to now focus on supporting more rings too. Just 2 rings aka kernel and usermode (and VT supervisor as third) is NOT enough in 2018.
You think they have the tooling to manufacture drop-in replacements for up to decade old CPUs, even if they wanted to?
Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase.
> Recent reports that these exploits are caused by a “bug” or a “flaw”
[Unprivileged] reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.
> any performance impacts are workload-dependent, and, for the average computer user, should not be significant
Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...
> However, Intel is making this statement today because of the current inaccurate media reports.
This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.
Has to be pointed out that they were correct. Public outrage forced them to change their tune, but their original summary was still on point. That said, it of course could majorly impact a select few.
I believe the point of this sentence was simply to distinguish malicious read access (possible) from any modifying access (impossible).
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
I believe the second half of the sentence is far more important, i. e. the attempt to broaden the news story to include other chip vendors. The scare-quotes around "bug" may suggest that Intel thinks they correctly implemented Tomasulo’s algorithm, and any flaw would not be theirs–which actually goes well with the second half of the sentence.
The part on performance is probably correct: Consumers might not notice any hit in performance. Gaming seems not to be impacted, and CPUs tend to be under-utilised anyway.
Overall, I think this statement is obviously damage control, but there really isn't anything wrong with the content from a consumer user of an Intel CPU. Basically: don't freak out, install patches, stay tuned.
The tone is actually refreshingly to-the-point. At least they are not taking us on a voyage to Qualityland.
Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....
That is lawsuit fodder.
- Saying it's not a 'bug' or 'flaw' = lie.
- Cold naming AMD and ARM in the post, I'm certain not just to throw their names in the ring but also for SEO ranking and relationships.
- Failing to address the root cause, how it came to be and provide other technical references.
And let's not forget - Intel's CEO sold his stock.
--
* Note: "AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-int...
Deleted Comment
> Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.
A rather bizarre statement of nothingness, and also an odd thing to say in a statement that just named AMD and ARM.
> Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
It's interesting to note what it doesn't say – as it would seem to imply that for some workloads the performance impact will be significant.
Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.
The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.
There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.
PCID is in Intels since Westmere.
We are not average computer users.
Exactly.
The "average" computer user may not notice the difference, but servers running Intel processors are used by businesses, hospitals, government, the military, cloud providers, and on and on. Often these organisations are thrashing this infrastructure to within an inch of its life.
Until fairly recently I was consulting and, no exaggeration, one of my former clients: if their SQL Server host takes a 15%, never mind a 30%, performance hit, they're screwed.
I personally have just been the prime mover in the procurement of a server costing £25k with a 3 year support contract, pretty carefully specced according to performance. And you're telling me I should be OK with that machine taking a 30% performance hit below what we specced? No way.
EDIT: Sorry, original version of last sentence was a bit out of order - the tone of that release got under my skin a bit.
1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
I don't think so. Given that both *nix and MS seems to have been working on this for at least a month already it can't have come as a surprise.
Particularly bizarre considering the use of "believes". If Intel disbelieved that their own products are the best in any particular respect, that might actually warrant a press release on its own.
Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're right but that's not a problem...
Short and sweet and has it all. If anything, it is a day late but monstrous organizations probably had a lot of bureaucracy to cut through.
People are so reactionary and quick to throw any company with a security issue under the bus, without ever having been on the other side of the table. The reality is issues happen to everyone and Intel wants to fix it.
You have a source for this claim? Because besides for Intel's press release I can't find any evidence that other manurfacture's processors are vulnerable to this bug.
Which is still intentionally misleading on Intel's part.
And specifically avoids mentioning that reading data is possible:
> Intel believes these exploits do not have the potential to corrupt, modify or delete data.
That's not taking responsibility. That's downplaying that the flaw exists.
A flaw their key competitor doesn't have, but they go on to mention several times just after they say things like " with many different vendors’ processors and operating systems — are susceptible to these exploits."
The entire thing has been written to be misleading. To pretend that the bug doesn't exist, and that AMD have it too, which is false.
"Working with key stakeholders" is not stating your course of action. At best, it is stating you are taking any action at all. I suppose that it is good that Intel has faith the stakeholders they are talking to are the important ones.
Dead Comment
Yes, many. Not your biggest competitor though, AMD. They're fine. And that may be the point you're trying to downplay here.
> Intel believes its products are the most secure in the world
Again, your biggest competitor, AMD, does not have this flaw. So precisely how is Intel the 'most secure in the world' if your biggest competitor is more secure than you?
The title of this post should be 'Intel PR Responds to Security Research Findings'.
I guess the goal is to produce the affect of reassurance when you don't actually have any substantive reassurance to offer. I wonder if this works, in general? My sense is that it always smells like bullshit, but I wouldn't necessarily recall instances where it didn't.
Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.
It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.
https://lkml.org/lkml/2017/12/27/2
There's this interesting post on RISC-V from roughly the same timeframe, that suggests it's not immune either: https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa...
But if they do they haven’t shared it.