Major Intel chip-level security flaw

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Winston

Lorenzo von Matterhorn
Joined
Jan 31, 2009
Messages
9,560
Reaction score
1,748
Denninger below speculates that one of the reasons that Intel maintains a single thread performance advantage over AMD CPUs which do not have this flaw might be due to this security jeopardizing cheat - "...their processors speculatively execute code in such a fashion that the actual access takes place before the privilege check is done. This is good for performance but horrible for security in that it apparently can be leveraged to allow the reading of anything accessible from the hypervisor -- in other words, any other client's data."

From AMD: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. 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."

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign
Other OSes will need an update, performance hits loom
2 Jan 2018

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

A fundamental design flaw (explained below - W) in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.

Are The Idiots On EC2 (and others) Ready? (EC2 is Amazon's cloud system - W)
by Karl Denninger
2 Jan 2018 07:00

As I have long maintained in the computing world unless you have physical control over a box and supervisory control over every single employee that has privileged access to said box you have no security whatsoever.

Period.

There will always be another bug. Or a "misfeature", whether it arises out of hubris, incomplete security review, hurried production or malfeasance of some sort.

There is now some evidence that exactly that sort of "you're screwed" problem has been discovered that may well be a hardware issue in at least some commonly used processors in so-called "cloud" environments.

This would, if true, allow one "client" to "jump the fence" and either access someone else's memory (in other words, a different client) or, much worse, possibly get them access to the hypervisor at which point all pretense of security on said box falls to pieces.

Please realize that any such breach is a "game over" sort of event because it allows recovery of active encryption keys and other highly-sensitive data in active use by said other customer/client. If I can get your encryption key I can pretend to be you (bad) or simply steal all your encrypted data and decode it (maybe worse!)

The pointer to some specific discussions on this point was sent to me by a reader -- and perusing through it, and where that led me, leads me to believe this is quite real and a handful of people are extremely worried -- not only about it but about keeping it real quiet.

The question is whether that's an attempt to forestall "bad guys" from using it or customers of some of the biggest cloud providers from discovering that it can impact them and fleeing.

Given where this looks like it's aimed and heading my money is on the latter.

Oh Oh
by Karl Denniger
2 Jan 2018 18:26

Hoh hoh it really is as bad as I thought.

At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs.

At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.

No, at worst it means the hole could be abused to read hypervisor data, including encryption keys from other user's workspaces, since the Hypervisor by definition must be able to map all the guest address spaces.

In other words all cloud computing environments are insecure.

What's worse it looks like the root cause of this is that Intel cheated. In other words their processors speculatively execute code in such a fashion that the actual access takes place before the privilege check is done. This is good for performance but horrible for security in that it apparently can be leveraged to allow the reading of anything accessible from the hypervisor -- in other words, any other client's data.

This is a really big deal folks. I've heard rumblings of a severe Xen problem (a common hypervisor) for a while now -- several months of relatively loud rumbling, starting with some little chirping about a year ago and change. If this is the issue and is embedded in the architecture of the CPUs involved in modern systems then any cloud-based system will be forced to use the mitigation code which will slow it down dramatically.

Incidentally "not doing that" turns a "one machine cycle for one instruction" thing into, in many cases, a couple hundred machine cycles. It's that bad and properly "fixed" via code workaround the performance bite will be taken on every system call.

The economic impact of this renders most so-called "cloud computing" arguments moot since we're talking performance hits of 30% or more for many common workloads -- especially those that make a lot of kernel calls!

You can bet the so-called "analysts" won't pay a bit of attention to this -- but they damn well should. The "correct answer" is change all the CPUs to ones without this flaw -- RIGHT NOW -- but I'm sure you can figure out how happy some CIO (or CEO, or investors) will be to hear that. The other answer is "buy 30%+ more CPUs to cover the performance deficit", which I'm sure will produce exactly the same sort of howl and should produce the same sort of hit to stock prices.

It probably won't, but it damn well should.

Then there's this -- it appears AMD's processors are not subject to this problem -- and it's been strongly hinted at by AMD that this is because they don't speculatively start execution of an instruction before determining whether it will result in a page fault. A common complaint is that AMD's chips are somewhat slower than Intel's for "equivalent" clock speed and capability (generation, etc.) Is the reason they were slower that Intel knowingly cheated and, if so, what implication does that have across the computing universe, especially in places where security is considered important like, oh, pretty-much everywhere?


------

Whereas AMD has its Infinity Fabric architecture which allows Moore's Law limits to be fought with the ability to link together multiple, smaller, higher-yield CPU dies which much more efficiently use a silicon wafer's area and which are, therefore, much cheaper to manufacture, Intel is currently stuck with their monolithic, everything on one huge, expensive, lower yield die technology. Now, they may lose the only advantage they have left for the bleeding edge, cost is no object, ultimate performance fanbois - slightly better single thread performance.

To make things even more interesting for the CPU consumer by providing even more competition for Intel, VIA (which bought the CPU manufacturer Cyrix years ago) has just announced plans to start producing their own CPUs.

Anyway, I have built all of my personal x86 PCs with AMD CPUs since day one for price/performance reasons. Recently, I watched the video below and will now avoid Intel-based systems simply out of principle. They nearly killed AMD with multiple instances of illegal behavior for which they were fined (not nearly enough):

[video=youtube;osSMJRyxG0k]https://www.youtube.com/watch?v=osSMJRyxG0k[/video]
 
Well, I was looking recently at AMD chips and remarking they looked really good and a better value than the Intel chips.

This just might have sealed the deal...
 
Intel CPU Bug Cannot Be Fixed With Microcode Update | Cripples Performance Up To 30 Percent

[video=youtube;9xhNY7v1R80]https://www.youtube.com/watch?v=9xhNY7v1R80[/video]
 
Intel CPU Bug Cannot Be Fixed With Microcode Update | Cripples Performance Up To 30 Percent

[video=youtube;9xhNY7v1R80]https://www.youtube.com/watch?v=9xhNY7v1R80[/video]
the hit will be mainly with virtualization, which most don’t do.
 
What does this have to do with Rocketry?

Why are you spreading fear and confusion here?


Sent from my iPhone using Rocketry Forum
 
What does this have to do with Rocketry?
This is the Off Topic section, and as such doesn't have to be rocketry related.

Why are you spreading fear and confusion here?
Many of us own computers and will be buying more computers someday, and this information relates to something that many of us have an interest in.


Why are you upset about this?
 
The short answer is, nobody really knows how big an impact this will be. This is a huge security flaw/problem, but really, nobody can do anything but wait for the expected updates. It's not like we can patch our OS's on our own.

When you do patch your computer, you will likely see a performance drop, depending on how much your software uses virtual memory. Estimates worth talking about haven't been developed yet, this is all super secret stuff (to prevent hackers from taking advantage of it), but there is fear and panic that computer performance could take a hit.

If all you are doing is web-browsing, email, and word processing, you probably won't notice a difference.

See:
https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/
 
It's worth noting that the performance hit of the software fix will only really affect computers running virtual machines. The affect on your home computer will be minimal due to the nature of differing workloads (5% or less is what I've gathered). That being said since Ryzen came out for the desktop scene at least Intel doesn't have a comparable product unless you're really optimizing a gaming experience where single thread execution is important, in which case you are still better off buying an AMD product, and spending the savings on a better GPU.
 
I used to be a Programmer, and a Unix and AWS sysadmin with 300+ servers to manage. Reading about this stuff, <slow deep breath> I can't express how relieved I am that I retired and it's no longer my problem. I feel for the techies in the trenches.

.... now... back to sanding fins..... :)
 
Lots of misinformation being spread by the news/media/anti-Intel folks. I'd wait for the January 9th announcement by the consortium (AMD, ARM and INTEL) included on this topic to see what ALL of these companies are doing with the exploit exposure.
 
the hit will be mainly with virtualization, which most don&#8217;t do.

Intel CPU Kernel Bug 50 Percent Performance Loss & CEO DUMPS Shares

[video=youtube;SBg_Hl6xkR0]https://www.youtube.com/watch?v=SBg_Hl6xkR0[/video]
 
It's Operating As Designed (ROFL!)
by Karl Denninger
2018-01-03 17:03

Intel's "big dude" was just on CNBC with a dog and pony show and a host asking questions who obviously doesn't know what the hell he's talking about.

CNBC's people should all be fired. Not bringing someone in to ask questions who actually understands what is going on here is criminally stupid -- but this is exactly what you'd expect from a channel that has as it's highest calling protecting the stock price of various firms.

Including Intel, I might add.

Let me make this clear:

Anyone who believes that a processor is "operating exactly as designed" when through any combination of unprivileged operations it allows access to data in a higher-privileged ring or one of equivalent privilege but not under the same guest instance, no matter how it happens, is a flat-out liar and in the context of a public company should be indicted NOW for making knowingly-false statements in relationship to their firm and its value.

To claim that this is not a "bug" or "flaw" is equally outrageous; this certainly was not documented or expected behavior by anyone. That is the very definition of a bug.

The entire premise of privilege "rings" on a CPU is to allow the partitioning of said CPU so that certain data can only be accessed or modified through a series of known, documented and permitted operations. Said operations then can implement whatever gating functions are appropriate and thus prohibit someone from extracting or changing privileged data without permission -- whether that extraction be from the supervisory code running with said privilege or from another "guest" running at a similar privilege to the item doing the extracting.

If you can get access to any such data via any other means then the entire premise on which the CPU's security model rests is void. As just one example of how ugly this can get if I can steal arbitrary data from the running ("ring 0") hypervisor that means I can steal a password hash used to access same or the allegedly-secure private key. Having done so I can then take all the time in the world to crack that hash offline or simply use said private key and now I'm able to sign into the hypervisor and steal all of the data and software from all of the guest instances on that physical piece of hardware, including any encryption keys that are in use and there is exactly no way for the victim guest(s) to know that it happened.

If you sell someone a product that represents it has such a security model and it can be breached in this fashion, and such person(s) bought that product believing that the security model actually works when it does not it is my contention you have committed fraud and are liable not only for the price of the CPU but also all the consequential damages that, in this case, include the cost of replacement motherboards and system RAM since newer-generation chips without said flaw will not work in the older boards and with older memory designs.

That there are "workarounds" that come with outrageously high performance penalties -- in this case it's being discussed that they may be as much as 50% or more does not change any of this. You didn't sell said processors disclosing that said "workarounds" were necessary and if you did you might not have sold any of said processors because at the degraded performance level they are likely worthless in the market when compared against others made by competitors.

Intel should be forced to buy back all of the impacted CPUs and the boards and RAM they run with at their original invoiced price, or to replace impacted system boards including the CPU, board itself and RAM with non-defective units of at least equivalent performance since newer CPUs will not socket into the existing boards -- and that assumes the chip is not soldered in place as is the case with some newer laptops, in which case the entire machine needs to be replaced.

Intel knows all of this and they also know that any such obligation imposed upon them going this far back into their product line would bankrupt the company so now what we have is a dance taking place with media figures that are too ****ing stupid to know what questions to ask and where and when to push back when the game of "dodge" takes place instead of taking that executive and skewering him on live television.

Oh, and if you think this is a "new" discovery by Google as claimed, and "nobody else has or has used it" -- you're nuts. That I may not be able to prove but there is utterly no reason to believe that state-level actors have had no knowledge of this until the last couple of weeks.
 
Lots of misinformation being spread by the news/media/anti-Intel folks. I'd wait for the January 9th announcement by the consortium (AMD, ARM and INTEL) included on this topic to see what ALL of these companies are doing with the exploit exposure.
From AMD: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. 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."
 
His largest sale of Intel stock ever by far on 29 Nov 2017. Foreknowledge?

Insider Trades of KRZANICH BRIAN M (Intel CEO):

https://www.nasdaq.com/quotes/insiders/krzanich-brian-m-872413

And this is interesting, too, this guy's largest sale of Intel stock ever by far on 30 Nov 2017.:

Smith&#8217;s planned retirement, which takes effect at the end of January 2018, follows the departure of PC and mobile group head Kim Stevenson in February and data center unit head Diane Bryant, who took a leave of absence in May.

Insider Trades of SMITH STACY J (group president of Manufacturing, Operations and Sales)

https://www.nasdaq.com/quotes/insiders/smith-stacy-j-759656

Intel Says CEO Dumping Tons of Stock Late Last Year 'Unrelated' to Big Security Exploit

https://gizmodo.com/intel-says-ceo-dumping-tons-of-stock-last-year-unrelate-1821739988

"Contacted by Gizmodo, an Intel spokesperson called the sale 'unrelated,' and said it 'was made pursuant to a pre-arranged stock sale plan (10b5-1) with an automated sale schedule.'"

Does Rule 10b5-1 Need Revision to Prevent Improper Insider Trades?

https://www.dandodiary.com/2016/06/...-revision-to-prevent-improper-insider-trades/

The SEC promulgated Rule 10b5-1 nearly 16 years ago to allow executives (whose wealth often is entirely locked up in company shares) to trade in their company&#8217;s stock without incurring possible liability under the securities laws. The Rule provides an affirmative defense against allegations of improper trading. In many cases defendants have relied on the existence of a Rule 10b5-1 trading plan in order to have the securities claims against them dismissed. However, the Rule has also been subject to criticism, and some have questioned whether corporate executives are abusing their plans in order to shield questionable trading.

A recent academic study corroborates the view that the plans &#8220;are being abused to hide more informed insider trading.&#8221; The study, by Gothenburg University Professor Taylan Mavruk and University of Michigan Business School Professor H. Nejat Seyhun and entitled &#8220;Do SEC&#8217;s 10b5-1 Safe Harbor Rules Need to Be Rewritten?&#8221; (here) concludes that &#8220;safe harbor plans are being abused to hide profitable trades made while in possession of material non-public information.&#8221; The authors suggest a number of revisions to the Rule in order to &#8220;prevent further abuse.&#8221;
 
I think the damage in credibility for Intel is more of an impact than the exact drop in performance.

I've been using AMD-only CPUs since 1999(Athlon). With the exception of the i5 in my newest one. After this, back to AMD 100%
 
From AMD: "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. 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."

Yup... https://www.reuters.com/article/us-...ly-all-phones-computers-at-risk-idUSKBN1ES1BO
https://www.bizjournals.com/sanjose...chips-security-flaw.html?ana=yahoo&yptr=yahoo

Might want to wait a bit for more info....
 
Found the 3 Jan Google report overview here:

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

Technical stuff here:

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

Tested Processors

Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)
 
Best (i.e., clearest and most concise) info I've found as of this morning:
https://www.nytimes.com/2018/01/03/...column-region&region=top-news&WT.nav=top-news

Summary:
1. There are two critical chip bugs/flaws that have been found.
2. Of these two flaws, there is a fix for one, and there currently is not a fix for the other.
3. The one that there is a fix for is the one that affects primarily Intel chips...this is called "Meltdown" and there will be security patches released soon. There is a fear that the fixes will potentially result in cpu slowdowns.
4. The other problem is called "Spectre" and it appears to be a fundamental flaw in the way that all current processors are designed. There is no easy fix for this, so just keep calm and carry on!
 
Best (i.e., clearest and most concise) info I've found as of this morning:
https://www.nytimes.com/2018/01/03/...st-column-region®ion=top-news&WT.nav=top-news

Summary:
1. There are two critical chip bugs/flaws that have been found.
2. Of these two flaws, there is a fix for one, and there currently is not a fix for the other.
3. The one that there is a fix for is the one that affects primarily Intel chips...this is called "Meltdown" and there will be security patches released soon. There is a fear that the fixes will potentially result in cpu slowdowns.
4. The other problem is called "Spectre" and it appears to be a fundamental flaw in the way that all current processors are designed. There is no easy fix for this, so just keep calm and carry on!
Thanks!
 

As a consultant, reseller and administrator, at this stage I am much more concerned about the impact of the lies and deceit that Intel played. Of course any security flaws are a concern, however they appear to be limited at this stage and the potential performance hit has a far greater long term impact.

Virtualization is a big part of the environments we manage today and the hardware is sized based on the load, with some headroom. We add headroom for several practical reasons. Those are, we take benchmarks with a grain of salt, in the majority of cases the server's role will change over it's lifetime so this provides some flexibility, and finally when systems age they tend to lose performance. However when you are talking about a potential 30% hit in CPU performance, specific to virtualization, this will undoubtedly reduce the service life of the asset considerably. It will also chew-up the majority headroom and in some cases it will have an immediate impact of performance of the virtual machines.

I see a lawsuit brewing against Intel, but from one of the linked videos that Winston provided, it looks like Intel is used to going to court. I have always supported Intel but after this I no longer trust them and will do my part to make their ethically deficient Exec team feel the pain. It's too bad that their CEO (Brian Krzanich) looks to be on his way out, it would be nice to see him taken to task on his little 24 million bonus, which by the sounds of it is just a drop in the bucket.

I can only hope that Brian Krzanich's moral and ethical bankruptcy dogs him and he is treated accordingly.
 
Last edited:
FYI, I see a lot of people using the term "virtualization." I take that to potentially refer to "virtual machines."

The "Meltdown" chip flaw which impacts the Intel chips has to do with "virtual *memory*" which impacts *everybody*. All modern OS's use virtual memory. I can guarantee you, you are using virtual memory right now.

The flaw particularly impacts cloud services, since the same server will handle multiple clients, and it would be a lot easier for a hacker to steal info from a server that handles multiple clients. In order to impact a single individual, the hacker would somehow have to install some malware onto your computer (which can be done, but takes more time/effort).

It still remains to be seen how much the fix will impact individuals (as well as cloud servers). All I can say is, if you are interested, benchmark your computer somehow now, before the fixes are rolled out, and then after you apply the fix.
 
I see a lawsuit brewing against Intel, but from one of the linked videos that Winston provided, it looks like Intel is used to going to court.
Beyond my quest for max price/performance, I was neutral on the Intel/AMD thing until I saw that video of Intel's multiple and serious illegal and anti-competitive actions which nearly killed AMD. That said, I sincerely hope that Intel is not seriously harmed by this because for the true competition to take place which benefits all CPU consumers, AMD needs Intel as much as Intel needs AMD to keep them both on the ball.
 
FYI, I see a lot of people using the term "virtualization." I take that to potentially refer to "virtual machines."

The "Meltdown" chip flaw which impacts the Intel chips has to do with "virtual *memory*" which impacts *everybody*. All modern OS's use virtual memory. I can guarantee you, you are using virtual memory right now.

The flaw particularly impacts cloud services, since the same server will handle multiple clients, and it would be a lot easier for a hacker to steal info from a server that handles multiple clients. In order to impact a single individual, the hacker would somehow have to install some malware onto your computer (which can be done, but takes more time/effort).

It still remains to be seen how much the fix will impact individuals (as well as cloud servers). All I can say is, if you are interested, benchmark your computer somehow now, before the fixes are rolled out, and then after you apply the fix.

Correct, it is intended to mean VMs and I understand the difference, however expand your Google search to intel+security+bug+virtual+machines. What you will see is a lot of industry speculation that the hardest hit will be servers running VMs. Of course this is early and somewhat speculative, however these conclusions aren't being pulled out of the thin air. On the surface they appear logical and legitimate, but time will tell.
 
I keep reading that the specifics of the issue are not being released in order to keep criminals from exploiting the problem. You know that anyone with the ability to exploit it are busy as heck trying to find what they can before anything is changed.

There's also very likely much more to this story that hasn't come out yet, like some criminals have already exploited the problem and that's how millions of accounts were hacked into at so-and-so company last year, or how the whatever bank was targeted, etc.

Maybe we'll find out that there was a major breach in security at the IRS because of this and so far it's been covered up successfully but we'll hear the full story next year after it's "fixed".

Or maybe it was actually found in time, they'll fix it soon, and it won't really be that big of a deal.
 
Correct, it is intended to mean VMs and I understand the difference, however expand your Google search to intel+security+bug+virtual+machines. What you will see is a lot of industry speculation that the hardest hit will be servers running VMs. Of course this is early and somewhat speculative, however these conclusions aren't being pulled out of the thin air. On the surface they appear logical and legitimate, but time will tell.

The issue isn't specifically with virtualization, but it makes it much easier to exploit. If you could install a program on an OS that hasn't patched this issue you could sniff at memory that doesn't belong to you, but the challenge is still installing that program in the first place (not that there aren't tricks to fool users into downloading/installing things, just makes it harder and generally involves tricking a user). But with virtualization, if you own one of the virtualized systems, installing software is easy (you have full control over that), and the protections that are supposed to prevent one virtualized system from seeing what's going on in the other one can be bypassed with this bug, apparently. So if you're running some important service on a virtualized system, someone else running on the same system could access your data, making VMs particularly at-risk since nobody ever had to compromise your VM, they're effectively peeking-in from the outside.
 
I keep reading that the specifics of the issue are not being released in order to keep criminals from exploiting the problem. You know that anyone with the ability to exploit it are busy as heck trying to find what they can before anything is changed.

This is the standard practice for most manufacturers, they announce broad details and release patches but not technical details.

The issue isn't specifically with virtualization, but it makes it much easier to exploit. If you could install a program on an OS that hasn't patched this issue you could sniff at memory that doesn't belong to you, but the challenge is still installing that program in the first place (not that there aren't tricks to fool users into downloading/installing things, just makes it harder and generally involves tricking a user). But with virtualization, if you own one of the virtualized systems, installing software is easy (you have full control over that), and the protections that are supposed to prevent one virtualized system from seeing what's going on in the other one can be bypassed with this bug, apparently. So if you're running some important service on a virtualized system, someone else running on the same system could access your data, making VMs particularly at-risk since nobody ever had to compromise your VM, they're effectively peeking-in from the outside.

I think you missed my point. As a systems integrator that hosts our own on-prem NOC, as well as an off-site data center, we provide both on-prem managed services and hosted, or as per the media hype, "cloud" services. Most (90%) of these systems are virtualized and all of the host servers are sized and priced based on several factors. A primary one at a high level being what can we comfortably deliver out of each box. If the worst case "fix" chews up to 30% of the processing power for the host then that may very well have an impact on the price of the services we deliver as well as force us to use up a lot of man-hours to re-balance our infrastructure.

However due to our philosophy the impact should be mitigated, it will depend on what the performance loss nets out to and it will apply on a case by case basis. We are a small player and a private company and we don't over-subscribe our service offerings, or as the bottom line driven execs view it, run a super efficient shop. In our case we consciously give up some profit and have a disproportionate amount of head-room/server. We can get away with this because we don't have share holders to answer to beyond the partners.

For the providers like Amazon, who view this as inefficient, if this "fix" results in what some predict then this could have a relatively substantial impact on the services they offer. At a min they may have to re-balance their infrastructure, which will consume many man hours and in some cases may result in interruption of services and or the need to procure additional hardware. This is speculative on my part but very plausible.

I am not dismissing the security concerns, although I might argue to the degree that you cited. However the concerns you bring up are primarily a moot point for us based on several reasons I won't get into, including our security model.
 
Back
Top