If you are a James Bond fan, you will likely remember that Spectre was an archenemy of 007, and in true Bond fashion, 007 successfully saved the world from the world-ending plot Spectre had planned. Therefore, it is quite fitting that Spectre and Meltdown are named for what are likely the worst and most pervasive hardware security vulnerabilities the industry has seen.
“Meltdown” and “Spectre” refer to two methods of exploiting a security vulnerability found in Intel, AMD, and ARM processors that, between them, threaten almost all PCs, laptops, tablets, and smartphones, regardless of the manufacturer or operating system. While many industry insiders suspected there were chip-level deficiencies in x86 chip, these accusations were never proven, and frankly, the industry has been reluctant to admit any potential vulnerabilities. Yet now that foundational weaknesses are known – and possibly well documented on how to exploit them – here come the villains to follow the blueprint.
Traditional approaches to address security vulnerabilities fall short
Addressing software vulnerabilities is a fairly straightforward process – develop a patch, issue it, so the customer can patch their environment. However, patching hardware security vulnerabilities especially those that are built into the chips themselves, is tricky because it is much more involved and generally takes longer to determine the best solution. The challenge becomes exponential when you consider that boards with these processors have been deployed over the last 20 years and have been included in many different types of computers around the globe.
According to the latest reports, most of the patches in the works have potential ramifications that could negatively, and quite significantly, impact performance and functionality of the chip. Most at risk: the features, including speculative execution and caching, which are used to improve the efficiency of processing multiple tasks in parallel. This is quite troubling because these features enabled long computational tasks to achieve performance improvements ranging from 10-30+%.
It is hard to say what the impact would be if these features were disabled, especially because each application was built under different assumptions, including compute availability and latency requirements. Yes, any real-time performance-oriented application is likely going to suffer either a performance hit, or any attempts to mitigate these risks will consume any additional processing power, such as available threads.
Losing 30% of the underlying server capacity is unacceptable in its own right, but it’s even worse when you consider they are already under pressure to meet processing requirements. In many cases, applications have either their own security vulnerabilities and need more larger code updates to run, or they need new supporting applications to help secure the applications and the data processed or produced. An easy fix is to purchase additional servers – a scenario that may sound good for the server manufacturers, but maybe not for companies forced to buy them.
Alternative approaches may not be appealing
What’s the alternative?
- Install higher performance servers? Not right now, as they likely still have the unsecure general compute processor. Plus, this approach disrupts everything for no gain, increases costs, and offers no more than a promise that it is more secure than what you have now.
- Move to the cloud? This model can be just as disruptive, and you still pay for the extra performance required. While it may be true that there could be future updates that are less disruptive, paving the way to move to more powerful instances. But the problem with running persistent production applications in the cloud is (much) more expensive than on-premise servers. Any potential return will present itself during the next “rip and replace” of hardware, which on average is every five years – that’s a long time.
A new approach
Fortunately, there are solution providers who have thought beyond these hardware challenges. These providers realize that organizations do not want to update their servers any sooner than they have to, and they have researched cloud pricing to see the tenuous promise of a return on steady-state application deployments.
Back to our James Bond example. Whenever Bond gets in a bind, it is usually Q’s cool gadgets that save the day. In this case, it is CSPi’s cool tool we call the “SIA”.
CSPi’s Myricom ARC Series Secure Intelligent Adapter (SIA) was built as a secure closed compute environment to provide additional and/or offloading of compute power. While process offloading is nothing new, the flexibility of our approach is fairly unique:
- The SIA can be placed in PCIe slots of legacy servers to provide 1/10/25G multiport NIC functions. So it likely fits in any device you have in an open slot or by replacing the legacy NIC card.
- It is designed to offload computing-intensive processes from just about any Linux and Windows server application.
With minimal effort, simple application connectors enable application developers to easily move computing-intensive processes (such as encryption) off of the server cores. This not only addresses the recently discovered hardware security, but it can also improve application and server performance. In addition, it can also offload things like web application firewalls (WAFs) and perform underlying network services like open vSwitch (OVS) In fact, it can offload heavy supervisor functions like those running NSX. It can readily reclaim multiple cores for each such function.
The cost-benefit analysis is simple – these NICs cost a lot less than replacing the existing servers with new ones. And they can improve performance while adding new functionality to better protect your legacy applications and the data they process.
While it may not the first thing you might think of to combat arch-villains like Spectre and Meltdown, CSPi’s SIA and other SecDevOps solutions are tools that, when applied by the right hands by the forces for good, can be a true game changer.