Intel re-bundles it with another vulnerability that also affects virtual memory management

A mysterious security error it affects all contemporary Intel CPU architectures that have the ability to implement virtual memory. A total redesign of these hardware architectures will probably be needed to solve the problem completely, but patches have already been worked to amend it from the software and the patches are already landing in the Linux kernel. In the case of Microsoft's systems based on Windows NT, they began to be solved in November of last year. Another case similar to the one we had with the known vulnerability that affected RAM memories and that was known as Rowhammer, compromising security.

Well, now this new problem could be affecting virtualization environments as common and used as the services of Amazon Web Services (AWS) EC2 and also those of Google Compute Engine among others. The truth is that the problem is not too serious, but the impact is broad due to the large number of architectures it affects, in addition to the fact that solving the problem using software is complicated. Specifically, the problem derived from this Intel error lies in the LWN, the kernel's page isolation tables, which intervene in memory management by the kernel. Then we find a complicated solution if it is done by software and that would not imply the best of the solutions and on the other hand we have to go to the root of the problem and redesign the hardware, specifically the affected architectures that allow managing this type of memory. That is not cheap or fast either, since we will have to wait for new generations of hardware that we would obviously have to acquire.

But going back to the software solution, that is, by patching, it is not good either as it would seriously affect the performance. Our CPU could have a considerable performance loss, up to 50%. Why? Well, to solve it, a code would have to be generated so that it empty the TLB memory (Translation Lookaside Buffer), a cache that speeds up performance considerably by locating faster where the data and instructions are located in the virtual memory of the system. But having to delete them every time the kernel starts and every time the user code resumes its execution, because the problem is notable ...