Intel Responds to Security Research Findings(newsroom.intel.com)
newsroom.intel.com
Intel Responds to Security Research Findings
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/
244 comments
Yeah, I had to read the “bug” or “flaw” part twice to be sure they're not saying it isn't a bug or flaw, they're only saying it isn't unique to Intel.
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
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
They could have just said other Industry vendors, but they HAD to name names.
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.
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.
Bet you a dollar some lawyer had to vet that three times over before they published it.
That same lawyer no doubt had to tell them that the following statement wouldn't fly without the addition of the word "believes":
"Intel believes its products are the most secure in the world [ . . . ]"
"Intel believes its products are the most secure in the world [ . . . ]"
Nicely done. Words like 'is' incur liability because it can be interpreted as making factual statements that you could be held accountable for. Hurry, get your law degree so you can skin Intel alive ;)
With the obvious class action suit that's coming, I don't know what else better their counsel has to do on a Monday night.
My suspicion is they don't get sued; rather, Werner Vogels calls Intel and tells them the massive haircut / refund they're gonna take. Or Werner buys amd procs.
Bet you another dollar it was more than one lawyer.
They said it wasn't the paragraph before
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.
(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.
> It's kind of semantics though isn't it?
I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed" is semantics. Calling something "semantics" isn't a defense to your argument; it's often more like a concession. (And the difference between a defense and a concession is, as I'm sure you realize, also semantics...)
I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed" is semantics. Calling something "semantics" isn't a defense to your argument; it's often more like a concession. (And the difference between a defense and a concession is, as I'm sure you realize, also semantics...)
Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning-
> A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree on the definitions of a word (or several words) essential to formulating the claim at issue.
When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed.
In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
> A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree on the definitions of a word (or several words) essential to formulating the claim at issue.
When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed.
In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
> When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed.
Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to the other person it might imply you are trying to stretch your own ideas to where they wouldn't apply.
Read your own definition: you said a semantic dispute is when they disagree on essential words. Not fluff words. People don't need to disagree on facts to have legitimate disagreements about about their interpretations and consequences. We all agree the CPU behaved in an undesirable way. There is no debate there, but that fact was insufficient to get us anywhere. What we disagree on is whether that is a "bug", which matters to all sides because it has consequences as who is to resolve the issue and how.
> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them.
[Edit: I misread part of the comment here; see below.]
If it's "unintended behavior", then, sure, the CPU has "bugs", but that's a pretty useless definition that gets you nowhere (especially legally). If it's "does not perform as specified", which at least to me is a more logical choice, then I'm afraid I have not seen a shred of evidence that they ever claimed memory contents are immune from CPU timing/cache/etc. effects.
Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to the other person it might imply you are trying to stretch your own ideas to where they wouldn't apply.
Read your own definition: you said a semantic dispute is when they disagree on essential words. Not fluff words. People don't need to disagree on facts to have legitimate disagreements about about their interpretations and consequences. We all agree the CPU behaved in an undesirable way. There is no debate there, but that fact was insufficient to get us anywhere. What we disagree on is whether that is a "bug", which matters to all sides because it has consequences as who is to resolve the issue and how.
> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them.
[Edit: I misread part of the comment here; see below.]
If it's "unintended behavior", then, sure, the CPU has "bugs", but that's a pretty useless definition that gets you nowhere (especially legally). If it's "does not perform as specified", which at least to me is a more logical choice, then I'm afraid I have not seen a shred of evidence that they ever claimed memory contents are immune from CPU timing/cache/etc. effects.
> ...you cannot seriously expect this to be a convincing argument without offering your own kosher definition (read: semantics) of "bug".
It's kind of hilarious that the only reason you can claim this is because of your selective editing. The whole statement you are responding too is this-
> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
Since you missed it the first time redcalx is already making the argument for me. I don't need to supply a separate version of the definition, I just need you to read the original message you were responding too.
It's kind of hilarious that the only reason you can claim this is because of your selective editing. The whole statement you are responding too is this-
> In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
Since you missed it the first time redcalx is already making the argument for me. I don't need to supply a separate version of the definition, I just need you to read the original message you were responding too.
Shoot, apologies for that, this was a silly reading error on my part... I quickly read that comment while outside and didn't realize 'redcalx' was referring to the user above, and instead somehow my brain just glossed over that part as a typo.
Disregard that part of my comment and look at all the rest of what I've actually been saying. The problem I have been trying to point out with the definition (as in the last comment, but I'll repeat here) is that the definition of a "bug" might be "just semantics" to you, but that doesn't make it irrelevant; those semantics make all the practical differences here. If you consider any undesirable behavior in unintended situations to be a "bug", then it sure sounds good, but won't get you anywhere, given that practically anything you buy can be used in weird ways with unforeseen (and hence unintended) consequences. If you consider a "bug" to be a deviation from the manufacturer's specified behavior, then it's obviously more limiting, but I would expect it's closer to the semantics a court would use to decide whether to hold the manufacturer responsible.
Disregard that part of my comment and look at all the rest of what I've actually been saying. The problem I have been trying to point out with the definition (as in the last comment, but I'll repeat here) is that the definition of a "bug" might be "just semantics" to you, but that doesn't make it irrelevant; those semantics make all the practical differences here. If you consider any undesirable behavior in unintended situations to be a "bug", then it sure sounds good, but won't get you anywhere, given that practically anything you buy can be used in weird ways with unforeseen (and hence unintended) consequences. If you consider a "bug" to be a deviation from the manufacturer's specified behavior, then it's obviously more limiting, but I would expect it's closer to the semantics a court would use to decide whether to hold the manufacturer responsible.
Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about that? The last one seems like the closest analogy.
Another example: would you say that MD5 is buggy/flawed?
I guess overall I think this is fair to call a "flaw" but not a "bug."
Another example: would you say that MD5 is buggy/flawed?
I guess overall I think this is fair to call a "flaw" but not a "bug."
I'd agree. The implementation conforms to the specification, so it's not a bug. The specification is flawed.
> I guess overall I think this is fair to call a "flaw" but not a "bug."
Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.
Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.
Reminds me of dieselgate. "Our product is ok unless operated out of spec" didn't work, iirc.
I think that analogy paints a pretty clear picture, this is a flaw because it's undesirable behavior in unexpected circumstances. A bug is unexpected behavior in expected use-cases.
I was about to say something like, "Well, in a broad sense they introduced protection features to x86 to prevent modification or disclosure of memory contents across process boundaries...and that's broken, therefore bug."
However, looking at the reference manual for the 80386 [1], and a modern version of their x64 manual [2], they don't actually say it's for security:
Original: "6.1 Why Protection? The purpose of the protection features of the 80386 is to help detect and identify bugs. The 80386 supports sophisticated applications that may consist of hundreds or thousands of program modules..."
Modern: "The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating systems."
So it's more like someone sells you a box with a lock on the front that looks a lot like a safe and all of the individual hinges and pins and whatnot are guaranteed to some degree, but they never actually say it's OK to lock your stuff inside.
[1]https://css.csail.mit.edu/6.858/2013/readings/i386.pdf
[2]https://www.intel.com/content/www/us/en/architecture-and-tec...
However, looking at the reference manual for the 80386 [1], and a modern version of their x64 manual [2], they don't actually say it's for security:
Original: "6.1 Why Protection? The purpose of the protection features of the 80386 is to help detect and identify bugs. The 80386 supports sophisticated applications that may consist of hundreds or thousands of program modules..."
Modern: "The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating systems."
So it's more like someone sells you a box with a lock on the front that looks a lot like a safe and all of the individual hinges and pins and whatnot are guaranteed to some degree, but they never actually say it's OK to lock your stuff inside.
[1]https://css.csail.mit.edu/6.858/2013/readings/i386.pdf
[2]https://www.intel.com/content/www/us/en/architecture-and-tec...
This feels pretty deceptive when the most relevant competitor, amd, is not susceptible...
[deleted]
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.
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.
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.
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.
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'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.
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]
[1] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
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...
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.
The third, I know nothing of.
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.
Ah, it must be serious, there's now a branded website [1] for it ;)
I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both.
[1] https://meltdownattack.com/
I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both.
[1] https://meltdownattack.com/
Reading the Meltdown paper [1], it's not clear why I keep seeing people say it's Intel only. The paper says quite clearly that other vendors' processors could be affected:
"Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors."
[1] https://meltdownattack.com/meltdown.pdf
"Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors."
[1] https://meltdownattack.com/meltdown.pdf
> "Instead, Meltdown exploits side-channel information available on most modern processors, e.g., modern Intel microarchitectures since 2010 and potentially on other CPUs of other vendors."
But their website faq says[0]: every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). .... Currently, we have only verified Meltdown on Intel processors....
[0] https://meltdownattack.com/#faq-systems-meltdown
But their website faq says[0]: every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). .... Currently, we have only verified Meltdown on Intel processors....
[0] https://meltdownattack.com/#faq-systems-meltdown
>...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."
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:
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).
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 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.
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.
Update: AMD has an official statement with a clear outline of the discussed vulnerabilities: https://www.amd.com/en/corporate/speculative-execution
Also wanted to point out that AMD's official statement was much better IMO.
Finally clarified this on my own and came back here to update a final time...but yeah this is the right answer.
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.
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.
> They said they verified Spectre attacks on AMD and ARM processors, as well.
https://www.wired.com/story/critical-intel-flaw-breaks-basic...
https://www.wired.com/story/critical-intel-flaw-breaks-basic...
Uh... they don’t say the exploits don’t allow for READING of data...
That’s the most concerning thing then
That’s the most concerning thing then
That's really the key.
"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.
"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.
> 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.
Intel wasn't being deceptive. That is exactly what they said, "software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data." This is in the very first sentence of their response.
Intel wasn't being deceptive. That is exactly what they said, "software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data." This is in the very first sentence of their response.
They also stated it does not have the potential to cause deletion, modification or corruption which directly contradicts the "malicious purposes" statement.
> They also stated it does not have the potential to cause deletion, modification or corruption which directly contradicts the "malicious purposes" statement.
You are mixing two different notions.
In security CIA = Confidentiality, Integrity, Availability.
Intel said that Confidentiality is broken by a security analysis applied maliciously (i.e. exploit), but Integrity is not. The general belief is that Availability is affected, due to a slowdown that depends on the workload.
You are mixing two different notions.
In security CIA = Confidentiality, Integrity, Availability.
Intel said that Confidentiality is broken by a security analysis applied maliciously (i.e. exploit), but Integrity is not. The general belief is that Availability is affected, due to a slowdown that depends on the workload.
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.
[deleted]
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.
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.
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.
That "bug" or "flaw" sentence is very carefully worded. It's like:
bool bug = true;
bool flaw = true;
bool uniqueToIntel = false;
bool reportsAreTrue = (bug || flaw) && uniqueToIntel;
// reportsAreTrue == false!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.
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.
Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
> Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
It actually doesn't even sound comparable to me, let alone worse. A wrong division is an operation producing incorrect results contrary to the specifications, plain and simple. What we have is a CPU producing correct results, and simply refusing to provide a guarantee about caching or timing. In particular it makes no guarantee that caching or timing behavior is data-independent. So it's not exactly hard to argue that it is not malfunctioning at all, and that people were (rightly or wrongly) simply assuming more about the CPUs than they were guaranteed.
Mind you, I don't like the bug any more than you do, and I would obviously like this to get fixed too. But it seems pretty hard to compare this with the division bug.
It actually doesn't even sound comparable to me, let alone worse. A wrong division is an operation producing incorrect results contrary to the specifications, plain and simple. What we have is a CPU producing correct results, and simply refusing to provide a guarantee about caching or timing. In particular it makes no guarantee that caching or timing behavior is data-independent. So it's not exactly hard to argue that it is not malfunctioning at all, and that people were (rightly or wrongly) simply assuming more about the CPUs than they were guaranteed.
Mind you, I don't like the bug any more than you do, and I would obviously like this to get fixed too. But it seems pretty hard to compare this with the division bug.
Wait, what? If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. Now the speculation about the underlying problem could be way off, but if not it would be hard to see how Intel would argue that it isn't a bug.
> If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue.
I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". You're muddying the waters here as to what you mean by "the issue". People often (even rightly) have "issues" with things that go beyond, you know, actual issues with those things. They do this because they extrapolate and their assumptions turn out to be incorrect, and they get annoyed (again, in this case, rightly so). And that's what I'm saying here: yes, this is a genuine issue for people, but no, far as I'm aware, all Intel has guaranteed is a certain behavior for each instruction, and as far as I'm aware, no specification has been violated. Hence this is a very different situation from one where they are violating their own specs and producing incorrect output.
If you can point to one guarantee in their specs that they violate (this may not be hard -- I have barely read their specs, given that they are thousands of pages), then I agree, this is potentially like the FDIV bug, and I would more than love to be aware of it. Until then, I see the two as quite different.
I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". You're muddying the waters here as to what you mean by "the issue". People often (even rightly) have "issues" with things that go beyond, you know, actual issues with those things. They do this because they extrapolate and their assumptions turn out to be incorrect, and they get annoyed (again, in this case, rightly so). And that's what I'm saying here: yes, this is a genuine issue for people, but no, far as I'm aware, all Intel has guaranteed is a certain behavior for each instruction, and as far as I'm aware, no specification has been violated. Hence this is a very different situation from one where they are violating their own specs and producing incorrect output.
If you can point to one guarantee in their specs that they violate (this may not be hard -- I have barely read their specs, given that they are thousands of pages), then I agree, this is potentially like the FDIV bug, and I would more than love to be aware of it. Until then, I see the two as quite different.
So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3, thereby rendering the concept of memory read protection useless by design?
> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3.
Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.
Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.
Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A 4-30
4.6.1 Determination of Access Rights
For user-mode accesses:
— Data reads.
Access rights depend on the mode of the linear address:
...
• Data may not be read from any supervisor-mode address.> 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.
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.
> Reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.
Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....
Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....
Source please?
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. ;)
Haha good point! That's what I meant of course :) edited for clarity.
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.
That is lawsuit fodder.
That is lawsuit fodder.
What a scummy, dishonest response.
- 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...
- 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]
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.
> 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.
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.
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.
That's probably a more accurate interpretation, but the wording is maddeningly ambiguous... just the fact that we can sit here and posit such wildly divergent interpretations is testament to how utterly woolly the statement itself is.
> 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.
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.
https://lkml.org/lkml/2017/12/27/2
It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).
It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).
I was making reference to this [1].
The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors.
[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
The original fix had a comment that literally said, "/* Assume for now that ALL x86 CPUs are insecure */" They've since added a check to exclude AMD processors.
[1] https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
Same patch I think.
That patch would be this git commit: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/...
Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).
Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).
I don't know if it's possible to see who contributed that patch (yet), but I’m cynical enough to half-expect that the “assume all x86 processors are insecure” patch might come from an Intel engineer...
I would not be surprised at all, considering the patch I saw for the AMD processors was literally a one-line if statement around the set cpu insecure flag that added a check for AMD processors.
Google is failing me or I'd post a link.
Google is failing me or I'd post a link.
the patch was by Thomas Gleixner[0], who is not an Intel Engineer.
AMD has since pushed a patch to "not enable PTI on AMD processors" [1]
[0] https://patchwork.kernel.org/patch/10138833/
[1] https://patchwork.kernel.org/patch/10142563/
AMD has since pushed a patch to "not enable PTI on AMD processors" [1]
[0] https://patchwork.kernel.org/patch/10138833/
[1] https://patchwork.kernel.org/patch/10142563/
You might mean this one:
https://lkml.org/lkml/2017/12//27/2
https://lkml.org/lkml/2017/12//27/2
Yeah.
I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
You mean enable KPTI.
Process Context ID for TLB entries to make the flipping efficient - if results in constant time failures, will solve the perf issue.
PCID is in Intels since Westmere.
PCID is in Intels since Westmere.
The 5% to 30% performance hit (dependent on workload) was measured with PCID. The hit may be more on older CPU's that do not support PCID.
So Intel might make out OK on this, since people will have to update their servers, and right now there are many more x86 server hardware choices which use Intel chips. The truly scary thing from Intel's perspective is if people decide to use this as an opportunity to move to AMD, or worse for them, completely outside the x86 ecosystem, to ARM64 or PPC64LE systems. I have heard accusations that Intel has strong-armed motherboard manufacturers so there are't that many choices for those other platforms --- at least so far. But of course, everything can change over time.
So Intel might make out OK on this, since people will have to update their servers, and right now there are many more x86 server hardware choices which use Intel chips. The truly scary thing from Intel's perspective is if people decide to use this as an opportunity to move to AMD, or worse for them, completely outside the x86 ecosystem, to ARM64 or PPC64LE systems. I have heard accusations that Intel has strong-armed motherboard manufacturers so there are't that many choices for those other platforms --- at least so far. But of course, everything can change over time.
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.
We are not average computer users.
We are not average computer users.
> 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.
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.
According to Google's Project Zero post [1], Intel has known about this since 2017-06-01.
1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
>Presumably the statement was hastily put together
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.
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.
But the story seems to only have broken to "mainstream" yesterday and has gained a lot of attention in the last 24 hours.
Sure. Catching mainstream media off guard is different from Intel though. There is no way this caught them by surprise.
If anything it reads like it was very carefully crafted by lawyers to make sure they don't get sued to hell for a defective product. (It's not but lawyers are gonna lawyer)
If anything it reads like it was very carefully crafted by lawyers to make sure they don't get sued to hell for a defective product. (It's not but lawyers are gonna lawyer)
They may not have realized it would make it to the media; until this week there was not much chatter, and then today Intel's stock is trading lower while every other chipmaker is trading higher. Their PR team may not have been prepared for that situation, and they may be worrying about CTOs giving more serious thought to AMD (or even non-x86 chips) for their data center upgrades.
> 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.
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.
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.
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.
https://lwn.net/Articles/740393/
...which was linked-to from this article: https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
...which was linked-to from this article: https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.
> The mitigation (KAISER) is being enabled for ARM as well as Intel x86 in the Linux kernel.
Is there a commit you can point to? Or a LKML discussion about this?
Is there a commit you can point to? Or a LKML discussion about this?
https://news.ycombinator.com/item?id=16058454 mentioned in one of the other threads on this topic
It's also manipulative, mentioning AMD and ARM for no other reason to make people think those also have the flaw.
ARM may have a flaw: https://lwn.net/Articles/740393/
ARM 64 does have the flaw. The tricksy wording is probably that AMD does manufacture some ARM 64 chips, so perhaps they were involved in that fix.
Which is still intentionally misleading on Intel's part.
Which is still intentionally misleading on Intel's part.
> 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.
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.
I don’t agree with you but your point is both defensible and well-argued, and I applaud that. That’s what civilised debate should be all about, right?
> 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.
"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'.
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.
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.
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).
We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do.
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.
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.
We know that AMD is not affected:
https://lkml.org/lkml/2017/12/27/2
https://lkml.org/lkml/2017/12/27/2
We know that "AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against." E.g. that AMD does not need the patch that Intel does. That is not the same as saying AMD is not affected at all.
We do not know what the actual bug that prompted this activity is. Nobody has revealed that information. It is possible that the bug affects AMD also but does not require this patch.
We do not know what the actual bug that prompted this activity is. Nobody has revealed that information. It is possible that the bug affects AMD also but does not require this patch.
The followup sentence: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
That is a pretty specific reference to the root of the problem, and a pretty clear indication that AMD's design decisions protect against whatever the attack is. Sure, we may find out that there is more to the attack than just speculative memory references, but so far what we have seen suggests a fairly specific vulnerability (that just happens to involve the particular design choices of a dominant chipmaker).
That is a pretty specific reference to the root of the problem, and a pretty clear indication that AMD's design decisions protect against whatever the attack is. Sure, we may find out that there is more to the attack than just speculative memory references, but so far what we have seen suggests a fairly specific vulnerability (that just happens to involve the particular design choices of a dominant chipmaker).
And, 17 hours later, we now know that there were three distinct vulnerabilities, of which one applies to AMD.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
Only under specific software configurations that are not enabled by default, or confined to a userspace single process (which is bad for web browsers running Javascript but not nearly as bad as the Intel-specific attacks). So while AMD is somewhat vulnerable, the most severe and easiest to exploit vulnerabilities are pretty specific to Intel. In a pedantic sense you were right, AMD chips are affected, but it is literally not on the same level as for Intel chips.
That's correct and it is a fair way to see it. However, Intel dragging two of its main competitors name into the limelight is a rather uncool move.
We know that people think that AMD is not affected by this permutation of the attack. Intel may know differently; I'd withhold sweeping claims.
"The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
Sounds like AMD's chips are not affected by variants of this attack either. Sure, we should wait for the details to be published before making sweeping claims, but the details we have so far paint a reasonable picture of what the vulnerability involves. It is reasonable to assume that AMD's design decisions prevent this attack, while Intel's decisions enable it.
Sounds like AMD's chips are not affected by variants of this attack either. Sure, we should wait for the details to be published before making sweeping claims, but the details we have so far paint a reasonable picture of what the vulnerability involves. It is reasonable to assume that AMD's design decisions prevent this attack, while Intel's decisions enable it.
You think Intel considers AMD vulnerable while AMD considers itself not vulnerable? That's quite an assumption to ask of us.
It was an AMD engineer, and he referred to specific details about a microarchitecture bug that seems to be important in this attack. So we are really being asked to believe that Intel's PR team knows more about AMD's microarchitecture than AMD's engineers (or that AMD's engineers are secret PR agents).
Would not be the first time vendor X knows vendor Y is vulnerable even as vendor Y denies it.
Now my interest is piqued: what instances of `vendor X` and `vendor Y` do you know of?
Well, at least one time I found a bug in OpenBSD, told NetBSD, then looked at their fix and discovered our fix was incomplete because my regress had a false negative. But up until that moment I was pretty confident about our fix.
I think that's sort of a pattern. Vendor X is affected by a POC, so they fix the issue. They then develop more tests. Vendor Y concludes they are not affected, perhaps based on a false negative test, and fails to investigate further. Now X understands more about the true scope of the problem than Y and they have tests to demonstrate on Y, but Y does not.
I think that's sort of a pattern. Vendor X is affected by a POC, so they fix the issue. They then develop more tests. Vendor Y concludes they are not affected, perhaps based on a false negative test, and fails to investigate further. Now X understands more about the true scope of the problem than Y and they have tests to demonstrate on Y, but Y does not.
[deleted]
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.
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...
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...
AMD manufactures some ARM 64 chips, which might make this "technically true" albeit intentionally misleading.
Intel may have code that shows PoC on other brands/ISAs.
But if they do they haven’t shared it.
But if they do they haven’t shared it.
Intel believes these exploits do not have the potential to corrupt,
modify or delete data.
Check with your operating system vendor or system manufacturer
and apply any available updates as soon as they are available.
Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits do have the potential to read data."
Yep, seems to me they put much work into the statement "the exploits do not have the potential to corrupt, modify or delete data.".
Which leaves open if (that?) reading of data is possible. And as this is not explicitly denied, we have to fear this is exactly what is possible.
Which leaves open if (that?) reading of data is possible. And as this is not explicitly denied, we have to fear this is exactly what is possible.
Yes as far as we know it allows user-space code to read kernel memory, but not modify it. It affects Intel but not AMD according to them (not sure why Intel says otherwise).
Details in this blog post from several months ago: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
They didn't get it to work but obviously someone else has.
Details in this blog post from several months ago: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
They didn't get it to work but obviously someone else has.
There are not saying it explicitly, which they should.
Yeah, sort of "Don't worry I'm not going to shoot you in the torso, arms or legs."
They are - literally the sentence before that states "methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed".
> 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.
Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?
Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?
Devils advocate.
Workload dependence... average user... not significant:
A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over-provisioned by 30% or more.
Mitigated over time:
Kernels are getting out safe patches ASAP, performance be damned. With more time to be careful, performance can be clawed back. And/or CPUs are upgrade and features such as PCID mitigate perf losses.
Workload dependence... average user... not significant:
A lot of users probably see "30%" and will assume the worst. There really isn't a lot of evidence of how much an average consumer will be affected. Pretty sure your average consumer isn't running pgbench all day. Hell, I'm willing to bargain 90% of servers (I really want to say more) are over-provisioned by 30% or more.
Mitigated over time:
Kernels are getting out safe patches ASAP, performance be damned. With more time to be careful, performance can be clawed back. And/or CPUs are upgrade and features such as PCID mitigate perf losses.
The problem is that "average users" pointedly does not include server and DB admins. I don't know about anyone else, but that's what I'm sweating over. We already know high I/O is what takes the biggest hit. I want to know what kind of a hit I can expect on our MSSQL VMs, and I am pretty sure the answer is not "minimal."
If you're running SQL in a VM ... I'm pretty sure I know how to improve your performance by 30%.
If you mean run on bare metal, not happening, due to MSFT's outrageous core pricing model. They force you to license every core available to the OS, whether you need the capacity or not. Running in a VM is the only way of getting around that requirement.
If you mean run something other than MSSQL — also not happening. Vendor lock in.
If you mean run something other than MSSQL — also not happening. Vendor lock in.
Given the potential slowdowns to be expected by the kernel fixes, I am not expecting a jolly January.
I work for a database vendor.
I work for a database vendor.
Considering Intel's dominance in the server space, I don't anyone is worried about the average user here
I mean, I am. I have a really nice laptop that I'd rather not have to replace.
Maybe wait until next week to decide if it needs replacing?
If you have malicious applications running on your laptop you have bigger problems already...
Malicious JS is fairly common on laptops... just see all the cryptominers.
The "put a big moat around it" approach to security should be put to rest. We isolate system processes and user accounts for good reason.
Interesting use of language:
'Recent reports that these exploits... are unique to Intel products are incorrect... Intel is committed to product and customer security and is working closely with many other technology companies, including AMD...'
Someone new to the issue might think AMD also has this problem.
Similarly (replacing the first elision in the above quote):
'Recent reports that these exploits are caused by a “bug” or a “flaw”... are incorrect.'
So, working just the way you want it to, eh, Intel? But then, why would you describe them as exploits?
'Recent reports that these exploits... are unique to Intel products are incorrect... Intel is committed to product and customer security and is working closely with many other technology companies, including AMD...'
Someone new to the issue might think AMD also has this problem.
Similarly (replacing the first elision in the above quote):
'Recent reports that these exploits are caused by a “bug” or a “flaw”... are incorrect.'
So, working just the way you want it to, eh, Intel? But then, why would you describe them as exploits?
Not defending Intel here, but devils advocate...
You will find many clients asking how to disable, for example, the Linux patch. Linux is releasing with a flag to disable it, so there is some merit. Why would you want that? There are a lot of times you trust everything running on your box and don't need to take the perf hit.
Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!
You will find many clients asking how to disable, for example, the Linux patch. Linux is releasing with a flag to disable it, so there is some merit. Why would you want that? There are a lot of times you trust everything running on your box and don't need to take the perf hit.
Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!
> There are a lot of times you trust everything running on your box and don't need to take the perf hit.
This is true.
> Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!
This I'm more skeptical of. My best guess is that this is something that saves nanoseconds, but the mitigation is massively more expensive than simply not having the feature.
This is true.
> Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!
This I'm more skeptical of. My best guess is that this is something that saves nanoseconds, but the mitigation is massively more expensive than simply not having the feature.
> Intel found a perf win that ends up having security implications.
Every Intel CPU has a lower perf than you will find on current benchmarks, but yes, there's a perf enhancement that will make the chip as fast as expected, but has security implications.
Every Intel CPU has a lower perf than you will find on current benchmarks, but yes, there's a perf enhancement that will make the chip as fast as expected, but has security implications.
Intel is certainly entitled to make and promulgate an objective assessment of the impact of the problem, but a problem is still a problem even if it doesn't affect everyone.
Who says they won't?
The issue is embargoed, but that's, as usual, not keeping everyone from speculating. That's fine too, but also realize the layman (even people in this thread) is getting pummeled with ideas like "my new laptop is going to be 30% slower tomorrow; WTF!!!"
The issue is embargoed, but that's, as usual, not keeping everyone from speculating. That's fine too, but also realize the layman (even people in this thread) is getting pummeled with ideas like "my new laptop is going to be 30% slower tomorrow; WTF!!!"
> Who says they won't?
Not me. My comments are restricted to certain things Intel did choose to say.
And as you are concerned about rumor and disinformation, I cannot imagine you are pleased with Intel's insinuation that AMD processors are also affected.
UPDATE: It seems AMD may be being misleading in this case...
Not me. My comments are restricted to certain things Intel did choose to say.
And as you are concerned about rumor and disinformation, I cannot imagine you are pleased with Intel's insinuation that AMD processors are also affected.
UPDATE: It seems AMD may be being misleading in this case...
Correction: it seems that AMD processors are also vulnerable to one variant of this type of attack, which either mitigates or refutes my first complaint. AMD is crying foul, claiming that Intel is creating a bogus equivalence, as the risks are not comparable, but it is itself using awkward phrasing: "AMD is not susceptible to all three variants" rather than the more straightforward "AMD is susceptible to only N of the three variants."
>Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
From the English, this report makes it seems like there was no bug and no flaw. However, they say that ((bug || flaw) && only_intel) is false, but I have seen that AMD was not impacted.
Seems like this is a bug or flaw, since they are addressing it soon. They make it seem like everyone should be working in the same boat to address this, but they are just trying to un-distance themselves from their competition.
From the English, this report makes it seems like there was no bug and no flaw. However, they say that ((bug || flaw) && only_intel) is false, but I have seen that AMD was not impacted.
Seems like this is a bug or flaw, since they are addressing it soon. They make it seem like everyone should be working in the same boat to address this, but they are just trying to un-distance themselves from their competition.
> since they are addressing it soon. They make it seem like everyone should be working in the same boat to address this
I can assure you that indeed "everyone is working in the same boat to address this", and has been doing so for months, across multiple OS and processor vendors. It's already public that Microsoft and Apple have also implemented page table isolation, and certainly Intel didn't name-drop AMD and ARM carelessly in the press release.
I can assure you that indeed "everyone is working in the same boat to address this", and has been doing so for months, across multiple OS and processor vendors. It's already public that Microsoft and Apple have also implemented page table isolation, and certainly Intel didn't name-drop AMD and ARM carelessly in the press release.
> and certainly Intel didn't name-drop AMD and ARM carelessly in the press release.
I'm sure it wasn't careless, but they are (from all accounts I have read) blatantly lying. Intel isn't known for above board practices. They will do what it takes to win - period.
Name dropping their competitors (to me), honestly shows me how dire of a situation this is. If it wasn't, they wouldn't feel the need to defend themselves and say, "well look at everyone else".
I'm sure it wasn't careless, but they are (from all accounts I have read) blatantly lying. Intel isn't known for above board practices. They will do what it takes to win - period.
Name dropping their competitors (to me), honestly shows me how dire of a situation this is. If it wasn't, they wouldn't feel the need to defend themselves and say, "well look at everyone else".
According to project zero report, a lot more than intel CPU's are affected by this issue. See relavant HN post here
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
https://news.ycombinator.com/item?id=16065845
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
https://news.ycombinator.com/item?id=16065845
> Intel believes these exploits do not have the potential to corrupt, modify or delete data.
No, but they do have the potential for privilege escalation or credential exfiltration, which in turn do grant the potential to corrupt, modify and delete data.
No, but they do have the potential for privilege escalation or credential exfiltration, which in turn do grant the potential to corrupt, modify and delete data.
Oh god, it's got a logo: https://meltdownattack.com
"Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
"Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."
> Intel believes these exploits do not have the
> potential to corrupt, modify or delete data.
That's strange, because I am pretty damn sure that with a working read_kernel_byte(u64 addr) primitive, I can gather enough info to corrupt, modify, or delete a lot of things.
> potential to corrupt, modify or delete data.
That's strange, because I am pretty damn sure that with a working read_kernel_byte(u64 addr) primitive, I can gather enough info to corrupt, modify, or delete a lot of things.
Something “operating as designed”, if designed incorrectly, is still broken.
Something that doesn’t “corrupt, modify or delete data” but does “leak” sensitive data to potential attackers, is still a serious exploit.
This is worryingly full of error-by-omission statements.
Something that doesn’t “corrupt, modify or delete data” but does “leak” sensitive data to potential attackers, is still a serious exploit.
This is worryingly full of error-by-omission statements.
Seriously? Their response is "It's not fair! ARM made the same mistake so you can't blame us!"?
Wow what a deceptive defensive response by intel. Nobody is concerned about data being deleted, it's the unprivileged access thats the issue here.
> Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available.
So coordinated patches to hit next week then.
So coordinated patches to hit next week then.
Intel's investor call [1] is underway and they are describing the attack vector(s). Rogue data load seems to be most concerning issue according to Intel.
Intel thinks this will need firmware and operating system updates to fully mitigate.
[1] https://www.intc.com/investor-relations/investor-education-a...
Intel thinks this will need firmware and operating system updates to fully mitigate.
[1] https://www.intc.com/investor-relations/investor-education-a...
This is not a security report, this is PR.
Among other things, it implies, without explicitly naming them, that AMD, ARM and OS vendors are being directly affected while most information out there point out it's merely an Intel issue.
Among other things, it implies, without explicitly naming them, that AMD, ARM and OS vendors are being directly affected while most information out there point out it's merely an Intel issue.
It does explicitly name them:
> 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 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.
I think what the parent comment means is that they're explicitly named, but not explicitly called out as being affected, just heavily implied.
Some ARM cores are genuinely implicated in this: https://news.ycombinator.com/item?id=16058454
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.
A possible reading of "not a bug or a flaw" could be "works as designed", or better, "works according to the spec". The spec probably never considered cache timing side-channels (if that's what the issue is) as something to be defended against.
A possible reading of "not a bug or a flaw" could be "works as designed", or better, "works according to the spec". The spec probably never considered cache timing side-channels (if that's what the issue is) as something to be defended against.
Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)
If the processor is 30% slower, the same amount of work is going to take 43% longer - right? If I'm renting machines by the hour my costs just went up 43%.
[deleted]
That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.
To be fair, this bug looks like it mostly affects systems that run lots of untrusted code -- e.g. cloud services. If you are only running code you wrote, that does not require many syscalls (compute heavy), in your own data center (or whatever), discounted Xeon chips that suffer from the flaw could be a good deal.
> even when a horrible defect is exposed
Are you sure AMD parts have no horrible defects of their own?
Are you sure AMD parts have no horrible defects of their own?
They would have to screw up really bad for people to go to AMD. I think that may never happen.
People who need to get absolutely the most bang for the buck have no ties to any given supplier. Cray deployed one of the first Opteron-based supercomputers.
Intel got lots of datacenter business simply by having a better (as in "better suited to our demands") product than anyone else in the segment. AMD has a short time window to make some large sales. They have until Intel ships a microcode fix or a new line of processors.
Intel got lots of datacenter business simply by having a better (as in "better suited to our demands") product than anyone else in the segment. AMD has a short time window to make some large sales. They have until Intel ships a microcode fix or a new line of processors.
> They have until Intel ships a microcode fix
Sounds like microcode fix isn't possible.
Sounds like microcode fix isn't possible.
Then the next generation it is.
It's a 5-30% performance boost without even a major change. :-(
It's a 5-30% performance boost without even a major change. :-(
Not disagreeing, but why do you say that?
Project Zero has published a detailed writeup on this. It's worth noting (in the context of Intel's response) that the P0 post confirms that AMD and ARM CPUs are also affected:
"Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01"
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
Edit: Discussion https://news.ycombinator.com/item?id=16065845
"Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01"
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
Edit: Discussion https://news.ycombinator.com/item?id=16065845
Do we know the actual bug yet? I sort of assumed it was a timing attack on KASLR rather than a leak of traditional kernel data.
Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...
Although I guess that there would have been cheaper mitigations like mapping an empty page to all of the other KASLR slots rather than doing a full world switch in that case...
[deleted]
It's true nobody knows what the actual bug is, but I was working with what Ars Technica described: "If the problem were just that it enabled the derandomization of ASLR, this probably wouldn't be a huge disaster... The industry reaction... suggests that it's not just ASLR that's defeated and that a more general ability to leak information from the kernel has been developed." https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
I guess I've stopped reading security articles by Peter Bright ever since he spent a whole series of articles shitting on project zero for disclosing vulnerabilities after the 90 day disclosure window when Microsoft had just been sitting on the bug.
https://arstechnica.com/information-technology/2015/01/googl...
https://arstechnica.com/information-technology/2015/01/googl...
Bigger than KASLR it seems.
https://twitter.com/brainsmoke/status/948561799875502080
Not good.
https://twitter.com/brainsmoke/status/948561799875502080
Not good.
That's a tweet of someone using the bug to defeat KASLR.
I'm fairly sure he's actually reading from the syscall table. He already defeated KASLR when he typed /proc/kallsyms.
That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.
That aside, I don't think KASLR would be important enough to rush KPTI like it has happened now and to even enable it by default, given its drawbacks.
Sorry, I'm being imprecise. Yes, they're reading from kernel memory. But the specific thing they're reading is useful as a KASLR bypass.
I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.
I think I understand that the subtext of this thread is: can you only bypass KASLR with it, or can you read pretty much anything from kernel memory? And yeah: it sure seems like you can work out arbitrary kernel values; it's hard to think of a way this bug could work where you can figure out the symbols of specific kernel functions, but not arbitrary values in the kernel.
If you know the specific kernel being used, all you have to figure out is the base address of the kernel to have to whole layout to break KASLR.
So if it had been a timing attack where an unmapped memory reference takes longer to fail than a memory reference with the wrong permissions, then you could scan all of the KASLR slots without actually reading back any data.
Actually reading data is a waaaaayyy bigger deal.
So if it had been a timing attack where an unmapped memory reference takes longer to fail than a memory reference with the wrong permissions, then you could scan all of the KASLR slots without actually reading back any data.
Actually reading data is a waaaaayyy bigger deal.
Yeah, that's true. I hadn't considered that the fragility of KASLR meant that there are lots of vectors for breaking it that don't require a huge chip break. Sorry, I'm making the thread dumber.
But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
By reading from the actual memory address, yes. Defeating kASLR with side channels is meh. Reading from actual addresses is a different matter entirely.
[deleted]
It looks like he's reading actual data from kernel space.
The best guess I've seen so far is this one: https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...
Actual information about the bug itself is still embargoed. Most people are assuming it's the attack you suggest based on recent commits, but it's a guess.
Additional information (PDF)[1] released as part of the Investor relations call[2] today:
[1]https://s21.q4cdn.com/600692695/files/doc_presentations/2018...
[2]https://www.intc.com/investor-relations/investor-education-a...
[1]https://s21.q4cdn.com/600692695/files/doc_presentations/2018...
[2]https://www.intc.com/investor-relations/investor-education-a...
"Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect."
The 'and' in this sentence makes this assertion correct and is very deceptive.
The 'and' in this sentence makes this assertion correct and is very deceptive.
The Register translation of the Intel spin is quite amusing:
https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...
https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...
This fails all 3 points on Scott Galloway's checklist of how to respond to a crisis. https://www.youtube.com/watch?v=PB-AyvgE8Ns
this is a denial from PR and a poor one at that.
What a strange response.
>many types of computing devices — with many different vendors’ processors
Really? Like who?
>many types of computing devices — with many different vendors’ processors
Really? Like who?
This probably means software is using CPUs in a way that they weren't meant to. To me, it is funny to watch how virtualization and JIT compilers changed the game for CPU vendors who were used to making CPUs mainly for compiling and running software on a single host instance. Since we have direct virtualization support now, I suspect we are going to get a JIT support in CPUs soon (if we didn't already).
> 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.
* sad trombone *
They're obviously not the most secure, as the Project Zero research shows. The whole press release has to be one of the most dismissive and snobbish PR pieces I've seen from a large corp.
* sad trombone *
They're obviously not the most secure, as the Project Zero research shows. The whole press release has to be one of the most dismissive and snobbish PR pieces I've seen from a large corp.
> Intel is committed to the industry best practice of responsible disclosure of potential security issues
No, the industry best practice is coordinated disclosure. The term "responsible disclosure" is a misnomer that we'd be far better off if we, as a society, stopped using it.
https://adamcaudill.com/2015/11/19/responsible-disclosure-is...
No, the industry best practice is coordinated disclosure. The term "responsible disclosure" is a misnomer that we'd be far better off if we, as a society, stopped using it.
https://adamcaudill.com/2015/11/19/responsible-disclosure-is...
Do you think the executive speculation has been well coordinated? :)
> Intel believes its products are the most secure in the world
Well, lol. It's a bit rich to say this in a vulnerability disclosure statement.
Well, lol. It's a bit rich to say this in a vulnerability disclosure statement.
This is a good time to bring up Intel ME. It is a black box and has already proven to have security issues. There maybe be more we do not know of. This paging flaw is accidental however Intel ME is designed to have unfettered control over all parts of the machine.
If Intel really believed in making secure products and believed in secure computing, they would remove Intel ME.
If Intel really believed in making secure products and believed in secure computing, they would remove Intel ME.
> Intel believes its products are the most secure in the world
https://security-center.intel.com/advisory.aspx?intelid=INTE...
https://security-center.intel.com/advisory.aspx?intelid=INTE...
"The most secure in the world" does not mean "flawless". Thinking like that is pretty dangerous (and silly)
I haven't seen any articles about AMD PSP security vulnerabilities yet, but there's a new one about IME every other month. If Intel truly is the most secure in the world, why are their CPUs riddled with security bugs big enough to drive trains through (IME has de facto become a integral part of Intel CPUs) and where are the news about non-Intel CPUs with similar bugs?
No, but it does mean more secure than anything else, which is pretty doubtful. Competitors to x86 have always had an advantage as far as security goes; then there is the ME mess; and now we have this latest bug. Nobody expects perfection, but Intel is not "most secure in the world" by any stretch.
True, but no one claimed that. We are, however, claiming that Intel is not the most secure in the world.
This, prior issues as linked, Intel ME, tons of undocumented instructions—some which mess up the system—, etc.
This, prior issues as linked, Intel ME, tons of undocumented instructions—some which mess up the system—, etc.
>Intel believes its products are the most secure in the world
After the Intel ME mess? I'm not so sure.
After the Intel ME mess? I'm not so sure.
If they believe it's not a threat, why the haste from the Kernel devs to fix KAISER?
[deleted]
Corporate-speak -> human-speak:
- Yes, the flow/bug exists
- We don't yet know if it can be successfully exploited at scale.
- It's quite possible that other CPU designs are affected as well, we don't have concrete data though. AMD and ARM have already started looking into the issue.
- Patches will be coming from as many manufacturers and as many OS-vendors as we can convince this is serious on a short notice.
- The patches do affect performance, often significantly, but there's nothing we can do in such a short period of time. We can only hope we can come up with better solutions down the line.
- Yes, the flow/bug exists
- We don't yet know if it can be successfully exploited at scale.
- It's quite possible that other CPU designs are affected as well, we don't have concrete data though. AMD and ARM have already started looking into the issue.
- Patches will be coming from as many manufacturers and as many OS-vendors as we can convince this is serious on a short notice.
- The patches do affect performance, often significantly, but there's nothing we can do in such a short period of time. We can only hope we can come up with better solutions down the line.
[deleted]
cyberpimp(2)
> 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.