Intel Responds to Security Research Findings
newsroom.intel.com
newsroom.intel.com
> Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
This is deceptive. It very quickly acknowledge the confidentiality aspect, but then claims that is "operating as designed" and then immediacy try to damage control by pointing out what the exploits cannot do (corrupt/modify/delete).
> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.
> Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.
This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem.
It then goes on with a straw man about performance impacts ("contrary to some reports").
And then mentions "average computer user" whereas the real problem is obviously not average computer users. Again, deceptive.
And then as you say, they immediately mention AMD to imply that everyone has the issue, but they also avoid actually saying that.
Your excellent analysis of what they're really saying reminds me of user thaumaturgy's analysis of Adancing Our Amazing Bet[1].
"Intel believes its products are the most secure in the world [ . . . ]"
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.
In the end, hardware and software devs in the 1970s were right. Operating systems like MULTICS and computers like PDP-11 got it right. MULTICS supported 16 rings and has many advanced features that almost everyone forgot and never implemented in newer OS - shame on all of us!
Intel CPUs barely support more than 2.5 rings (if you count the VT that just blowed up). Also operating systems need to now focus on supporting more rings too. Just 2 rings aka kernel and usermode (and VT supervisor as third) is NOT enough in 2018.
You think they have the tooling to manufacture drop-in replacements for up to decade old CPUs, even if they wanted to?
That’s the most concerning thing then
"No problem here, move along, move along - you won't be able to modify/corrupt/delete that password, you can only read it in plain text. Nothing to see. Move on."
IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour.
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.
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.
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 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.
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."
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.
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...
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...)
> 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.
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.
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.
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.
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.
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.
https://www.wired.com/story/critical-intel-flaw-breaks-basic...
It looks like (some?) AMD processors might be affected as well: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."[1]
[1] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon.
The third, I know nothing of.
I believe the Intel only issue is called "Meltdown" and the second is called "Spectre"; the attack website [1] has details of both.
"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....
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."
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.
This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner?
I read this as Intel trying to imply that other vendors weren't probed and/or may not have this specific design vulnerability but can still be vulnerable...which I consider a vapid statement designed to distract the reader.
True, when a 0-day is found and disclosed it doesn't mean that there aren't other 0-days that haven't been found yet...but that has no relation to the significance of the newly disclosed vulnerability.
I judge this statement even more harshly because the flaw is so serious it's under embargo until OS vendors can try to protect users. Additionally, AMD seems to have said their processors are not vulnerable (https://lkml.org/lkml/2017/12/27/2)...
Edit: Some more information from Google Project Zero:
https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
So maybe AMD and ARM are vulnerable?
Edit 2: So it seems there are two slightly different attacks along this vector: Spectre and Meltdown. From the Google article(s) it seems Spectre affects Intel, AMD, ARM while Meltdown only affects Meltdown. This would appear to contradict the AMD statement regarding their processors not being affected.
I am not hardware guy and information is still coming out...but I am judging this Intel press release slightly less harshly (although it still reads pretty vapid).
The Spectre paper seems to be a bit less specific on how platforms might differ under explotation but very clearly states that it was verified to be possible. Workarounds for that problem will likely be much more application specific from what I can tell, but I have only skimmed that paper so far.
Unless you view a key or password... then use it to corrupt, modify or delete data.
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.
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.
Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....
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.
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.
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.
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.
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.
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.Documentation: Data may not be read from any supervisor-mode address.
Published vulnerability: Data may be read from any supervisor-mode address.
bool bug = true;
bool flaw = true;
bool uniqueToIntel = false;
bool reportsAreTrue = (bug || flaw) && uniqueToIntel;
// reportsAreTrue == false!That is lawsuit fodder.
- Saying it's not a 'bug' or 'flaw' = lie.
- Cold naming AMD and ARM in the post, I'm certain not just to throw their names in the ring but also for SEO ranking and relationships.
- Failing to address the root cause, how it came to be and provide other technical references.
And let's not forget - Intel's CEO sold his stock.
--
* Note: "AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-int...
> 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.
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.
Quoting ARM and AMD is really a bit pathetic too, IMHO, especially if it turns out that AMD chips are immune to the flaw.
PCID is in Intels since Westmere.
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.
Another possible interpretation: the early patches will create performance issues, but we'll issue subsequent patches that will make the performance issues less noticeable.
Not saying this is the right interpretation, just another possibility.
The official fix for this in the Linux kernel has a comment that literally says to assume all x86 processors suffer from the same issue and will disable KPTI for all x86 processors, including AMD.
There's an AMD-specific patch that I saw floating around that keeps the setting enabled for AMD processors, but I'm not sure if it made it into the mainline.
Google is failing me or I'd post a link.
AMD has since pushed a patch to "not enable PTI on AMD processors" [1]
It makes reference to the nature of the bug and explains why AMD's chips are not affected (from an AMD engineer).
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...
I just found it in their git repo, looks like it was added today. https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip...
Not yet on the mainline AFAIK, but I'd guess that whole branch will be merged soon (before the next release candidate).
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.
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.
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)
1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...
Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're right but that's not a problem...
Short and sweet and has it all. If anything, it is a day late but monstrous organizations probably had a lot of bureaucracy to cut through.
People are so reactionary and quick to throw any company with a security issue under the bus, without ever having been on the other side of the table. The reality is issues happen to everyone and Intel wants to fix it.
You have a source for this claim? Because besides for Intel's press release I can't find any evidence that other manurfacture's processors are vulnerable to this bug.
Is there a commit you can point to? Or a LKML discussion about this?
...which was linked-to from this article: https://arstechnica.com/gadgets/2018/01/whats-behind-the-int...
Which is still intentionally misleading on Intel's part.
"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.
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.
Yes, many. Not your biggest competitor though, AMD. They're fine. And that may be the point you're trying to downplay here.
> Intel believes its products are the most secure in the world
Again, your biggest competitor, AMD, does not have this flaw. So precisely how is Intel the 'most secure in the world' if your biggest competitor is more secure than you?
The title of this post should be 'Intel PR Responds to Security Research Findings'.
I guess the goal is to produce the affect of reassurance when you don't actually have any substantive reassurance to offer. I wonder if this works, in general? My sense is that it always smells like bullshit, but I wouldn't necessarily recall instances where it didn't.
Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.
It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.
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.
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.
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.
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).
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
But if they do they haven’t shared it.
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...
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.
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.
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.
Given the lack of any facts, evidence, or details in the press release, how is anyone supposed to take Intel seriously?
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.
If you mean run something other than MSSQL — also not happening. Vendor lock in.
I work for a database vendor.
'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?
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!
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!!!"
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...
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.
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.
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.
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'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".
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
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.
"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."
> 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 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.
So coordinated patches to hit next week then.
Intel thinks this will need firmware and operating system updates to fully mitigate.
[1] https://www.intc.com/investor-relations/investor-education-a...
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.
> 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.
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.
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.
Sounds like microcode fix isn't possible.
It's a 5-30% performance boost without even a major change. :-(
Are you sure AMD parts have no horrible defects of their own?
"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
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...
https://arstechnica.com/information-technology/2015/01/googl...
https://twitter.com/brainsmoke/status/948561799875502080
Not good.
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.
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.
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.
But, I mean: that's what that dude is doing in that tweet, is all I'm saying. :)
[1]https://s21.q4cdn.com/600692695/files/doc_presentations/2018...
[2]https://www.intc.com/investor-relations/investor-education-a...
The 'and' in this sentence makes this assertion correct and is very deceptive.
https://www.theregister.co.uk/2018/01/04/intels_spin_the_reg...
>many types of computing devices — with many different vendors’ processors
Really? Like who?
* 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.
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...
Well, lol. It's a bit rich to say this in a vulnerability disclosure statement.
If Intel really believed in making secure products and believed in secure computing, they would remove Intel ME.
https://security-center.intel.com/advisory.aspx?intelid=INTE...
This, prior issues as linked, Intel ME, tons of undocumented instructions—some which mess up the system—, etc.
After the Intel ME mess? I'm not so sure.
- 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.