This form logs you into your management portal account. To access your help desk account, click here and use the form to the right of the news.
Steadfast Public Cloud CPU Side Channel Vulnerability Information
Posted by Kevin Stange, Last modified by Kevin Stange on 09 June 2020 05:53 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This article provides current support information for Spectre, Meltdown, and related side channel vulnerabilities on the Steadfast Public Cloud. Here is a summary of the currently known issues:
The information contained in this article makes assumptions specific to Steadfast's Cloud environment and they are not necessarily applicable to other clouds Current System StatusThe following table describes the current issues and the fix status for each:
The status information indicated above may vary for customers with dedicated hypervisors based on maintenance arrangements. We are continuously working to keep dedicated hypervisors in line with the public cloud. Platform HistoryThe current public cloud platform has been patched against Meltdown and Spectre variant 2 attacks. The platform is based on CentOS 7 and Xen 4.8. Prior to February 11, 2018, the platform was based on CentOS 6 and Xen 4.4. Xen 4.4 will not receive updates to fix either Meltdown or Spectre. On January 17th, the first patches that mostly mitigate Meltdown were made available for Xen 4.8, but no patches are yet available to mitigate Spectre. Our migration to Xen 4.8 was the culmination of several months of testing and planning, which we started prior to disclosure of the security issues. We did not modify our plans as a result, other than to increase the urgency of our roll-out. On February 23, 2018, the first available Xen patches which mitigate variant 2 of Spectre became available, however the solution required a compiler update and microcode updates that were not yet available on CentOS. We deployed the update with initial mitigation once the compiler update was available in April. In early June 2018, we deployed CPU microcode updates once they were made available by Intel to mitigate Spectre variant 2 using CPU assistance. In early August 2018, we deployed a version of Xen containing the Lazy FP fix as well as performance improvements related to the Meltdown fix. The fix for Speculative Store Bypass and Spectre v3a was included, but not effective at that time. We deployed the required microcode update to support the SSB fix in late September 2018. Available information indicates no fix is required in Xen for Spectre variants 1, 1.1, and 1.2. Available information indicates that SpectreRSB and NetSpectre are proof of concept attacks for which the Spectre v2 fixes provided mitigation. There are two different fixes for L1TF depending on the VM operating mode. A complete fix for Windows VMs required a microcode update (the same as the SSB microcode update) and to disable hyperthreading features of the CPUs. A complete fix for Linux VMs requires only a Xen software update. The necessary code updates for L1TF were deployed in late September. Hyperthreading was turned off completely in the environment in early 2019 to fully mitigate risks to Windows VMs. MDS mitigation requires a new CPU capability which requires microcode updates for all affected processors, hyperthreading must be disabled, and Xen and guest kernels must be updated to take advantage of the new capability. We obtained the required microcode on June 19, 2019 and all hypervisors were fully patched by July 2, 2019. SWAPGS mitigation requires no action on the hypervisor because Xen does not use the vulnerable CPU feature. TAA mitigation requires no action on the hypervisor because the CPU does not support the vulnerable feature. SRBDS does not affect the hypervisor because the CPU does not support the vulnerable feature. Important: To fully take advantage of all available mitigations it is necessary to upgrade your VM to the latest available kernel or Windows update version, then fully shut down and boot up the VM. This will ensure that the CPU capabilities provided by the new microcode are seen by the OS and used optimally. Current Risks to VMsDue to the way Xen is designed, Linux VMs do not need Meltdown kernel patches inside the VM. They already cannot exploit the Meltdown issue using the normal Linux method. However, Xen must be fixed to prevent users on Linux VMs from exploiting Xen directly to read the memory of other VMs on the same physical server. Windows VMs cannot exploit the Xen variant of the Meltdown vulnerability, but Meltdown can be exploited inside a Windows VM to read its own memory from an unprivileged account unless the correct Windows Update package has been installed in the VM. Linux VMs may be able to exploit the Xen issue to read the memory of unsuspecting Windows and Linux VMs even if they are patched. Both types of VMs are vulnerable to Spectre, however the amount of exposure caused by Spectre is more limited and thus less of a danger overall than Meltdown. Some of the system updates available may mitigate part of Spectre, but the availability of patches varies wildly by operating system. Xen patches along with CPU microcode are required to provide complete mitigation for Spectre and other side channel issues. Current Mitigation OptionsThe most complete mitigation available is running on patched hypervisors. All public cloud VMs are currently on these hypervisors since February 11th and are being kept up to date with patches are soon as they are ready. If you are running Linux, you should also apply kernel updates that provide fixes to Spectre and other Side Channel issues. Updates fixing Meltdown and TAA are not required. Please note that working kernels are now available for all CentOS VMs that fix all variants up to and including MDS:
If you are running Windows, you should apply Windows updates to patch issues up to and including SWAPGS:
Important: After applying updates you should fully shut down your VM, then start it back up from the control panel. This ensures the VM boots up with awareness of microcode features that enable all fixes to be effective. If you trust your VM users, you may also want to consider a dedicated hypervisor, which guarantees all the VMs on the physical server are under your control. This option does not itself prevent side channel vulnerabilities from being exploited, but limits the number of people who may have access to the server memory. Keep in mind that if you operate applications that face untrusted users, an exploitable vulnerability in such an application could allow a user to run their own code and subsequently exploit Meltdown, Spectre, or other side channel vulnerabilities. If you'd like to explore the option of switching to private hypervisors, please contact our sales team for further information. References
If you need any help or have any questions regarding any of this information, please contact our support team. UpdatesJune 9, 2020 @ 5:45 PM
June 9, 2020 @ 12:50 PM
November 11, 2019 @ 3:15 PM
August 7, 2019 @ 12:30 PM
July 2, 2019 @ 5:30 PM
June 25, 2019 @ 11:40 AM
June 19, 2019 @ 4:30 PM
May 20, 2019 @ 3:05 PM
September 24, 2018 @ 5:15 PM
September 14, 2018 @ 2:30 PM
August 30, 2018 @ 3:55 PM
August 30, 2018 @ 11:30 AM
August 1, 2018 @ 11:05 AM
July 17, 2018 @ 5:15 PM
March 13, 2018 @ 3:00 PM
February 12, 2018 @ 10:45 AM
February 7, 2018 @ 6:35 PM
January 26, 2018 @ 3:35 PM
January 22, 2018 @ 1:45 PM
January 18, 2018 @ 6:30 PM
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|