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.\nLinux distros are rolling out fixes, and Microsoft has issued patches for Windows \u2014 although the threat to consumers is minimal. Apple has also issued a macOS fix.\nThe 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.\n\n\u201cThis 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,\u201d said Zac Smith, CEO of cloud provider Packet.\nAlready the impact is being felt by cloud customers. One developer showed his Amazon EC2 instances taking a notable performance hit. That\u2019s 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.\nHow single tenancy protects against the Meltdown exploit\nSo, 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.\nMultitenancy is part and parcel of how most virtual environments operate, especially cloud providers. Amazon, Microsoft and Google all control the VMs \u2014\u00a0and you are sharing CPU space with who knows who. IBM is the only one of the big providers that offers what\u2019s known as bare-metal hosting, meaning you provide the entire software layer, from the OS on up. It\u2019s done through its SoftLayer subsidiary, although Amazon just recently announced plans to offer bare-metal solutions, as well.\nWhile 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.\nPacket 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.\n\u201cWhat 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\u2019t want performance hits and understand their own security of single tenancy,\u201d he said.\n\nThese 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.\nUsually it\u2019s 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\u2019t running random workloads, and they aren't allowing random users to access the app space.\n\u201cSome 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\u2019t feel they will be affected by this,\u201d said Smith.\nHe added that this is not a panacea, but if you are using a VM on a public cloud, you\u2019re at risk. Whereas if you run your own workload on a locked-down, single-user environment with your own kernel, it\u2019s good. No other users are capable of exploiting memory access.\nFor now.