What does Spectra and Meltdown mean for developers?
One of the first steps executed when booting a computer is patching the processor with a firmware update. Virtually all CPUs of all vendors released in the last 40 years contain bugs. Most of them are trivial, many mild, some are severe, a few critical, and then you have Meltdown. Of the two recent security bugs found on Intel processors, Meltdown could arguably be the worst security CPU bug ever found.
Meltdown affects most Intel processors manufactured since 1995 and allows hackers to bypass the hardware barrier between applications run by users and the computer’s core memory. The problem is especially severe in a virtualized environment where a hacker with access to one of the VMs could bypass security and read the memory contents of all the machines hosted physical server.
The fix keeps kernel and userland memory more carefully apart so that side-effects from speculative execution tricks are mitigated. All this is good, but this change is not free. As a side effect, it tampers with caching. As CPU caching is one of the main tricks for a CPU to boost performance, anything that reduces the effectiveness of the cache is likely to produce a performance hit, as is the case.
You can compare this fix to the HTTPS protocol, which adds a layer of security on top of HTTP but makes it computationally more expensive.
The low level OS fix required to secure our computers is probably the most radical change in OS design we have seen in years, as it basically changes how your operating system manages memory for the running processes. The implications are profound.
Arguably the most important of these implications is that the toolchain we use to build our applications has to be adapted to produce optimal code to target this new design.
For us, it has two main consequences:
- Update our build tools (compilers, etc.) to the latest version.
- Make sure all the source code from our applications, including third-party modules or dependencies, is properly recompiled.
As usual, legacy code that can’t be updated, obsolete dependencies or third-party unmaintained libraries will be our main adversaries. I boldly predict that many applications will be rewritten from scratch to solve the performance issues described in this article.
Applications running on Linux may have an advantage here over the Windows counterparts and their migrations should be smoother. Big Linux vendors recompile all the packages in their repositories with every new version to take advantage of the new compiler, kernel and glibc optimizations and developers rarely install dependencies outside the supported channels.
Unfortunately this toolchain update and recompiling discipline is rarely known in the Windows world where backwards compatibility is king. We all know application that can only be compiled with a particular (and obsolete) version of Visual Studio or, even worse, abandoned nuget packages that are critical for a particular application (or that DLL with a fancy name whose source code is lost in time)
But it’s not all bad news.
A big breaking change is a chance too. For example, a chance to activate security features that are now disabled by default for compatibility reasons, get rid of obsolete features or entire subsystems, rethink optimizations, etc. It’s a chance to modernize and improve the very same foundations on top of which we build our applications. In short: to evolve.
If you are already a Bluekiri customer, you can rest assured our infrastructure is being updated with the latest security patches as soon as they become available.
The majority of Bluekiri customers should not see a noticeable performance impact with this update. We’ve worked to optimize the CPU and disk I/O path and are not seeing noticeable performance impact after the fix has been applied.
Additionally, if you are impacted by performance degradation or want to start planning an upgrade to your legacy code, feel free to start a conversation with us :)
