Americas

  • United States

Is single tenancy the fix for the Meltdown flaw?

Opinion
Jan 08, 20184 mins
Data CenterIntelSecurity

One way to prevent snoopers is to not let others in.

As the fallout continues over the Meltdown and Spectre exploits in Intel and now some ARM processors, the issue of what to do about it is coming front and center. Clearly there is no fixing a silicon problem; Intel will have to adjust future chips to deal with it. So, for now, we have the software fixes.

Linux distros are rolling out fixes, and Microsoft has issued patches for Windows — although the threat to consumers is minimal. Apple has also issued a macOS fix.

The problem is these fixes are being hurried out thanks to Google publishing a virtual roadmap to the exploit. Google sat on it for seven months, but it was known only to Intel, ARM and AMD. The Linux guys were informed late, and as a result, they had to hurry their patches.

“This was a rushed set of kernel patches. There were little optimizations. This mitigates the exploits, but with a hammer. The question is how much performance can we get back with updates,” said Zac Smith, CEO of cloud provider Packet.

Already the impact is being felt by cloud customers. One developer showed his Amazon EC2 instances taking a notable performance hit. That’s because as Amazon rolls out kernel updates, the virtual machines (VMs) are being rebooted with the fix, which is estimated to impact performance by as much as 20 to 30 percent.

How single tenancy protects against the Meltdown exploit

So, you are seemingly stuck with two bad choices: Run without the fix and risk the exploit biting you, or issue the fix and suffer performance degradation. Smith argues there is a third solution: single tenancy.

Multitenancy is part and parcel of how most virtual environments operate, especially cloud providers. Amazon, Microsoft and Google all control the VMs — and you are sharing CPU space with who knows who. IBM is the only one of the big providers that offers what’s known as bare-metal hosting, meaning you provide the entire software layer, from the OS on up. It’s done through its SoftLayer subsidiary, although Amazon just recently announced plans to offer bare-metal solutions, as well.

While this advice comes from a cloud provider, it works on-premises, as well. If your network is closed, and you are restricting access to high-performance applications such as data warehousing, business intelligence, online analytical processing (OLAP) or big data apps, then you can be reasonably confident no one will get at them.

Packet is a tier-two cloud provider that specializes only in bare-metal deployments. The customer provides everything in the software layer. And Smith noted that many customers are running single-tenant scenarios with highly controlled environments and are shunning the Meltdown fix.

“What we heard from our customers is some are very interested in applying both kernel patches and updates, while others want to stay unpatched. The reason is they have use cases. They don’t want performance hits and understand their own security of single tenancy,” he said.

These customers have a common profile: They are very performance-driven and are running one workload at a large scale. They know their code well, are not sharing it with anyone and have highly modified the operating environment.

Usually it’s for performance-intensive tasks, such as extract, transform load (ETL) or big data, and companies have no desire to slow their workload by up to 20 percent, they aren’t running random workloads, and they aren’t allowing random users to access the app space.

“Some of our most opinionated customers are highly advanced in how they are approaching this. Some specifically asked how they can disable kernel patches from OS upstream. They feel confident in their own single tenancy and how they run their code that they don’t feel they will be affected by this,” said Smith.

He added that this is not a panacea, but if you are using a VM on a public cloud, you’re at risk. Whereas if you run your own workload on a locked-down, single-user environment with your own kernel, it’s good. No other users are capable of exploiting memory access.

For now.