sommai - Fotolia
Foreshadow mitigation obscures licensing impact
Performance of virtual machines could be severely affected by the workaround for Intel’s latest processor flaw. To compensate, more processors will be needed
Businesses running Intel-powered servers in their datacentres may need to buy one-third more server licences to ensure system performance is not reduced after applying the Foreshadow fix.
Mitigation against the recent Intel chip flaw could lead to datacentres requiring more processor cores to retain the same level of performance that they had previously. Inevitably, this will affect any per processor-based software licensing.
Businesses mitigating against Foreshadow have been warned that the extra processing power needed may result in the need for 30% more per processor licences.
In August, Intel published figures showing the performance impact that users may incur if they apply Intel’s recommended mitigations against Foreshadow (L1TF) processor attacks.
It said there would be no performance impact on non-virtualised environments or where it can be guaranteed that all virtualised guest operating systems are trusted. But there are a number of scenarios where the hypervisor cannot be trusted.
Intel said: “For a portion of the market – specifically a subset of those running traditional virtualisation technology, and primarily in the datacentre – it may be advisable that customers or partners take additional steps to protect their systems. These additional steps will depend on the system software in use, the workload, and the customer’s assessment of the security threat model for their environment.”
For instance, VMware has provided a new feature called ESXi Side-Channel-Aware Scheduler. But it warned: “This feature may impose a non-trivial performance impact and is not enabled by default.”
In an advisory to its customers explaining how they can protect their datacentre systems against Foreshadow, Red Hat said: “L1TF is a significant threat to virtualised environments, especially those that contain a mixture of trusted and untrusted virtual machines. Fortunately, L1TF can be mitigated with a modest cost to system performance.”
Hyper-threading is one of the key technologies that enables modern x86 processors to run virtualised environments without a performance hit.
In a hypervisor, a physical processor core is managed as multiple virtual CPU cores mapped onto the physical hardware. Each can be dedicated to run a computing task. Hyper-threading effectively enables another task – known as a thread – to run on the same processor core if the thread that was previously running on the processor core is idle.
Disabling hyper-threading
Disabling hyper-threading is among the mitigation strategies being proposed to protect against Foreshadow, but it appears that the industry is passing on this responsibility to its customers.
On server operating systems older than Windows Server 2016, Microsoft has recommended disabling hyper-threading. But Windows Server 2016 offers a new feature, which, according to Microsoft, offers little performance impact.
On the company’s virtualisation blog, David Hepkin, partner development manager at Microsoft, wrote: “Starting in Windows Server 2016, Hyper-V introduced a new scheduler implementation for SMT (logical processor) systems known as the ‘Core Scheduler’. When the Core Scheduler is enabled, Hyper-V schedules virtual cores onto physical cores. Thus, when a virtual core for a VM is scheduled, it gets exclusive use of a physical core, and a VM will never share a physical core with another VM.”
In effect, the mitigation that Microsoft has developed appears to dedicate a physical processor core to a thread running a computing task – similar to disabling hyper-threading – but the blog does not explain how the Core Scheduler avoids the performance hit that would occur if hyper-threading is disabled.
Red Hat said the precise impact of L1TF to hyper-threading depends on the specific use case and the virtualisation environment being used. “In some cases, it may be possible for public cloud vendors (who have often built special-purpose hardware to assist in isolation) to take steps to render hyper-threading safe,” it said.
“In other cases, such as in a traditional enterprise environment featuring untrusted guest virtual machines, it may be necessary to disable Intel hyper-threading. Since this varies from one use case to another, and from one environment to another, Red Hat and our peers are not disabling Intel hyper-threading by default.
“Customers should instead consult our Knowledge Base article and make the appropriate determination for their own situation.”
Intel said: “In many of those cases, Intel hyper-threading will not need to be turned off in order to provide full mitigation. Consult your hypervisor vendor for more guidance.”
But, by Intel’s own admission, the impact of disabling hyper-threading is significant. Its published SPECvirt_sc2013 benchmark data shows that with hyper-threading turned off, the mitigation results in a 31% drop in performance.
Read more about processor flaws
- Intel will not issue patches for legacy processors, so older systems and legacy embedded applications will remain vulnerable to Spectre exploits.
- At RSA Conference 2018, Paul Kocher, who co-discovered the Spectre flaws, discussed the chip vulnerabilities and explained why disclosure and mitigation efforts were so troubled.
Rival chipmaker AMD sees this as an opportunity to replace Intel-based servers with AMD-powered datacentre hardware. Daniel Bounds, senior director of AMD’s datacentre and embedded solutions group, said: “Foreshadow drastically reduces performance of virtual machine environments. To mitigate against Foreshadow, you need to turn off hyper-threading – so your virtual CPU count goes down by half. And if you apply the Intel patches, your performance reduces by a third.”
Potentially, said Bounds, there is also a software licensing impact. For the same level of performance, a patched system adversely affected by the Foreshadow workaround would require one-third more processor cores to retain the same level of performance.
As such, the business may find that it not only needs to allocate more processor cores to run a given workload, but additional software licences will also be needed to maintain the existing level of system performance.
For instance, using the processor licensing for Oracle database Enterprise Edition, a six-core licence for x86 servers would normally require two processor licences because Oracle stipulates a 0.25x charge for each processor core on the server. If hyper-threading is disabled and the server has to be upgraded to eight cores to keep the same level of performance, the licensing cost will remain at two processor licences.
But if the business originally ran an eight-core server and then switched off hyper-threading as part of its Foreshadow mitigation, the Oracle database would require 10.6 cores to achieve the same level of performance as the original eight-core server.
Extra processor charge
Under Oracle’s licensing, the customer would incur a charge for an extra processor. In effect, the CPU fix would require 2.6 processors to be licensed, but this would be rounded up to three – or 12 cores – for the purpose of Oracle’s processor licence.
SonicWall CEO Bill Conner warned that the combination of Foreshadow and the previous Spectre processor flaw create a cocktail that, from a security perspective, can get extremely dangerous very quickly.
But as well as plugging the security holes arising from these flaws, businesses will now need to assess the performance impact, and, as a consequence, whether they will require more datacentre CPU capacity, and accept that more processor-based licensing will be needed.
This potentially toxic situation has meant there is very little information readily available to businesses trying to gauge the real impact of the security steps being recommended to mitigate against a potential Foreshadow attack.
“Intel is now going back to developers and saying ‘you can’t publish performance stuff’,” said Conner. Switching off hyper-threading is part of the mitigation, but this has the biggest performance impact, he said.
“The minute you go from multi-threading to single-threading, your performance is going to get hit, because performance is the whole point of multi-threading,” Conner added.
