It has emerged that Intel CPUs made in the last decade or so are missing proper checks when it comes to securing Kernel Memory. It would seem that through special (undocumented) steps, a User-Mode application can peek and make changes to Kernel-Mode Memory. This means that any application, such as your browser, can access and change your system memory.

Some theory

In the 32-bit era, an application could typically access up to 4GB of RAM; this has been de-facto for ages. What really happened is that the application had access to 2GB of for User-Mode memory (used to typically hold the memory needed by the application to function). The other 2GB is mapped to Kernel space, containing memory locations for Kernel-Mode memory.

In the 64-bit era, these memory limitations were lifted since a 64-bit architecture can access such a larger address space (16 exabytes, to be exact). Given that the Kernel-Mode memory is so much larger (248TB), the OS can randomly place it anywhere it pleases, randomly. This randomness (Address space layout randomization) successfully makes it so much harder for foul-playing applications to find the addresses of Kernel-Mode functions.

So, what’s happening?

Typically the code that runs in User-Mode (typical code) does not have access to the Kernel-Mode memory. The reason why this is done is so when an application switches to Kernel-Mode (needed for example to open a file from disk), the Kernel-Mode memory would still be accessible, avoiding the needed to have 2 memory tables, one for User-Mode and one for Kernel-Mode. Having more than one table will mean that during every sysenter (or equivalent), tables will need to be swapped, cache needs to be freed and any overhead that such operations require.

It would seem that on Intel CPUs, hackers have found a way to bypass this security feature. This means that a User-Mode application can now access Kernel-Mode memory; which is devastating. A User-Mode application can apply small changes to the Kernel and change its functionality. Since an application has access to Kernel memory, a hacker can basically do whatever he pleases with the target’s system.

How can this be fixed?

Unfortunately, an easy fix is not available. The whole memory management logic needs to be re-written, so that instead of having just one memory table, which maps both User-Mode and Kernel-Mode memory, an additional table will hold the Kernel-Mode memory; this table will be only accessible from Kernel-Mode memory. The change is being dubbed as Kernel page-table isolation (KPTI, known as KAISER).

Adding a new memory table and switching to-and-fro has negative effects on the overall system performance, especially in I/O heavy applications. The reason is that I/O involves a lot of User-Mode and Kernel-Mode switching. Given that the new code needs to run every time the system switches from User-Mode to Kernel-Mode. performance degradation are expected. Unofficial figures quote between 5%-30% performance impact, depending on the application. OC3D has provided some benchmarks; FS-Mark (I/O benchmark) show a devastating hit in performance. PostgreSQL said that there is a best case of 17% slowdown, worst case of 23% using new new Linux patch.

Which operating systems are vulnerable?

Basically, all Operating systems are vulnerable to this hack. this is because this is a bug that goes beyond the operating system, since it lives on the CPU rather than on an operating system level. Scary! Vendors have been (secretly) informed of this issue and are working on fixing the vulnerability:

• Linux has submitted its first round of updates
• Windows has submitted fixes to Windows Beta testers to try out the new fixes Alex Ionescu has already demonstrated that such functionality has been in development since November at least on Windows.
• No mention of macOS at the time of writing. UPDATE: Apple has already rolled out an initial fix for macOS on December 6. Apple still working to further enhance such feature.

Are non-Intel CPUs vulnerable?

All we know at the moment is that AMD CPUs are NOT vulnerable. This has been confirmed by AMD themselves. In fact, Tom Lendacky from AMD has issued a fix for the Linux kernel itself, adding a check so that if the CPU is AMD, the mitigation is not applied.

What’s next? How can I stay safe?

If you got an AMD CPU, well then congratulations, you’re safe! If you’re on an Intel System, don’t panic just yet. Yes, you are vulnerable, but yes, you still control what you do with your computer. If you don’t visit dodgy websites and don’t install dodgy applications, you’ll remain safe. But that’s age-old advice.