About the new CPU vulnerabilities

[Edge100x]

The just-publicly-announced processor bugs related to speculative execution are very serious for any host that runs customer-provided code, whether virtualized or not. We have been working hard internally to apply currently-released mitigations required for them quickly, as we wait for other mitigations from our vendors (for Windows, Linux, and firmware with new Intel microcode, for instance).

These bugs are complicated, but fundamentally, they allow untrusted code to leverage how CPUs released in the last 20 years work behind-the-scenes to get access to data in other parts of memory that the code shouldn't be able to reach -- allowing processes to read secret keys and passwords stored in kernel memory, for instance. Limited attacks can even be performed using Javascript run from inside a web browser. The defense for such exploits involves changing how the CPU behaves and better-isolating user code, but mitigations come at an unavoidable performance cost, estimated by some to be around 5%. The cost is higher for software that interacts with the kernel more often, such as through frequent I/O.

On our end, we have two primary concerns: Securing shared hosting platforms such as game servers and webhosting (where a customer could run an exploit that accesses our data or other customers' data); and securing virtual machine hosts (where a customer could run an exploit that accesses anything else on the same machine). In terms of the former, we will be applying OS updates and potentially separate firmware updates (which Microsoft requires but Linux does not, because Linux is designed to support loading new microcode at run-time). These will require reboots. In terms of the latter, we are minimally impacted because the big exploits only apply to Xen's "PV" domains and those running on specific older hardware; but, we will be needing to change how our Managed Linux and webhosting platforms are managed, which will require additional reboots for only customers with Managed Linux servers and those using our shared webhosting.

On the customer side, any customer with an unmanaged VDS or unmanaged dedicated machine will need to update the OS, at minimum, after fixes become available.

Some sites that talk about the newly-discovered bugs in depth:

https://meltdownattack.com/
https://spectreattack.com
https://googleprojectzero.blogspot.com/ ... -side.html
https://support.microsoft.com/en-us/hel ... xecution-s

[Technut]

Thanks for your timely post. I appreciate the explanation of the impact on your services. I'm confident that you are on top of the problem and are already planning the solutions. Keep up the good work!

[MPQC]

So I have a question. If I understand the bugs correctly, these are hardware bugs that are being fixed through software. In the case of anything you guys control (i.e, managed system) then there's no issues on our end - I assume you'll do the OS update & reboot and that'll be the end of it. But is there any information regarding the people on VPS's sharing a machine? Could a customer simply install (or rather, not update their OS) and still be able to abuse this?

[Edge100x]

These are fairly complicated bugs and vendors are still working out how best to defend against them, as well as how to do it in ways that best retain performance levels.

When it comes to concerns about customers on the same virtual host getting access to data on your VDS, you will be protected against Meltdown (the worst of the three classes of bugs). The two Spectre variants are more complicated to defend against, but also much harder to exploit, with more limited information disclosure. Vendors, including Xen and Intel, are still working out how to deal with Spectre and generate the patches needed for their products (which are not yet available). There will likely be multiple rounds of updates over the next few months as they pin down the best ways.

In terms of what you need to do as a user, the solution for one of them (Meltdown) involves separating the OS and programs into different address spaces. That is a solution that can be implemented by the OS itself. Linux has does it, and you can get that fix (if you run Linux) by updating the kernel to at least 4.14.11. Applying the same fix for Windows currently requires changing several registry entries and then updating through Windows Update, as described in their article.

Code: Select all

Key="HKEY_LOCAL_MACHINE" Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat" Value="cadca5fe-87d3-4b96-b7fb-a231484277cc" Type="REG_DWORD”

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

The solution for the other two (Spectre) involves much deeper software changes and microcode updates. These microcode updates haven't yet been released for most hardware, and the software changes needed in concert with the microcode updates aren't yet available for most platforms (including Xen and Linux). We'll all have to wait for developments on those ones.