The biggest story in the tech world over the last week has been the Meltdown and Spectre security vulnerabilities.  So what are they, and how will the fixes for them impact games?

This post will focus on the Meltdown attack as the implications of that are more serious and we’ve seen that the patches coming out to fix it are causing some problems.

The attack exploits speculative execution – a performance feature of modern processors which allows them to guess what instructions are about to be executed and start executing them in advance.  The technical details are well covered elsewhere so I won’t go into detail – if you want to find out more take a look at the Meltdown Attack site.

The result of the Meltdown attack is that it is able to read data from kernel memory – memory that only the operating system itself should have access to.  This is especially bad as this memory could contain passwords or caches of sensitive files that the program shouldn’t be able access.  In order to stop the exploit, the operating system must set up and then clear up mappings that allow access to kernel memory each time a program calls into the kernel, which means there is a performance penalty, especially if programs call into the kernel a lot.

Kernel calls are required to read or write data to the disk or network, to set up graphics rendering or to allocate memory.  However, games are already optimised to minimise the number of kernel calls while they are running, because kernel calls were already quite expensive.  For example, game programmers normally ensure any data is loaded from disk in advance and on a different thread to the main game thread to avoid performance penalties.  Although setting up graphics rendering requires kernel calls, data transfer to the graphics card is done through shared memory so few kernel calls are required each frame.  Therefore, the framerate of games running on your own machine are unlikely to be affected much.

CPU load on background threads performing network and disk access might be increased slightly, but normally games are limited by the performance of a single thread which is focussed on gameplay and physics updates, so this is unlikely to make a noticeable difference to framerate.  That said, load times are likely be impacted as they are generally limited by disk access – it will be interesting to see whether there is a noticeable affect there.

However, the impact on servers is likely to be more significant – as was seen on the Fortnite servers this weekend.  The reasons for this are two-fold, first the server is much busier with network traffic as it sees the traffic from every client.  Additionally any user authentication or tracked persistent data, such as player stats, will mean it’s accessing and updating databases on disk.

But there’s a second issue that compounds the problem – the server is likely to be running in a virtual machine on a hosting provider.  This increases the complexity of the fix, as there must be isolation between the memory owned by the kernel memory of the virtual machine and the kernel memory of the physical host machine.  Therefore, protection must be added twice (and hence a double performance penalty applies) – once between the process and the virtual machine OS, and once between the VM and the physical host.

Despite the performance impact, these vulnerabilities are too severe to leave unpatched.  So if developers can’t find a way to make optimizations to gain back the lost performance, in the end the fixes are likely to increase server hosting costs.