social network

A new day, a new vulnerability in Intel processors (not so large)

The optimization of FPU in Intel processors (which appeared in the 1990s) proved to be vulnerable to reading from another process (including the virtual machine process)

In each CPU, there are registers (32-64 bits in length), which are the lowest-level processor structure available to OS developers. However, in addition to the usual registers (which are used for operations on integers), there are separate parts of the processor that make the hotel operations faster.

Just such a part is the FPU (floating point unit), which is responsible for operations with fractional numbers. FPU itself has its registers, and in new processors they can be 512 bytes long (for additional instructions from the MMX / SSE / AVX sets). In sum, they can store several kilobytes of information.

Whom do FPU registers worry at all? If I understand correctly, then Intel AES (and some other crypto programs) uses FPU registers to store cryptographic keys.

In each CPU, processes periodically change each other to ensure multitasking, when there are more processes than process kernels. This happens quite often, so that the user does not notice that only one process can work on the kernel at any one time. When the FPU just appeared (~ 1990), access to it was not very fast, so optimization was used (if the process does not touch the FPU, we will not save it and clean it so that it does not restart later (because of the size of the FPU registers it was relatively This optimization is called the lazy FP switch, so that other processes can not read the unused FPU memory, a special mechanism was used (if the special bit is 0, then if you try to access the FPU, save and clear its registers). ,

How much is it terrible? It seems to be not very. In linux, this optimization was disabled by default in the kernel 4.6 (2016), removed at 4.10 finally, motivating that “in modern processors FPU is fast, and optimization almost never works.” In windows 10, windows server 2016 this (seemingly) is also disabled, but server 2008 is vulnerable (the full list of vulnerable OSs is deleted on Intel’s request).
OpenBSD and DragonflyBSD released patches (actually, because of them about the vulnerability and found out, so it was an embargo until August).

The question arises, but maybe it’s not AMD behind, and Intel is just sprinkling with optimizations that are potentially dangerous?

http://blog.cyberus-technology.de/posts/2018-06-06-intel-lazyfp-vulnerability.html

Back to top button