Meltdown is such a big issue since it breaks down a fundamental assumption of the operating system that user in user mode does not have access to the information stored in kernel memory, which may contain some sensitive data. Since people can not really avoid the vulnerability in processor hardware, the only mitigation of Meltdown is actually in the operating system kernel. As soon as Meltdown goes public among people, companies have released their patches to fix this vulnerability. At this point, kernel page-table isolation (KPTI) seems to be the most efficient solution.
Before the KPTI mitigation, user and kernel modes are actually sharing the same page table. Based on people’s original assumption, user mode can not access information in kernel memory (arrow 1). However, Meltdown proves people wrong. It turns out that with the help of out-of-order execution, people can actually access that sensitive information in kernel memory, applying Meltdown(arrow 2).
This is the place where KPTI comes to assist.KPTI helps to restore the assumption we mentioned above. This mitigation gives each application two sets of pages tables rather than one and switches between them on every kernel-to-user and user-to-kernel transition. In other words, KPTI separate user-space and kernel-space memory entirely. Thus, when attackers try to access the data in the kernel memory in user mode, they can not use the user-mode page table to point to the kernel memory, since those can only be accessed by using kernel-mode page table, which can not be pulled up in user mode.
However, KPTI comes with pros and cons. Because of the separation of page table, page table swap happens on each system call, interruption and exception, and these swaps may have some impact on the performance of the processors. Even though there are only few extra instructions on each swap, the translation lookaside buffer (TLB) is cleared each time. The TLB is a cache that stores the virtual and physical memory pairings. When the processor tries to access data in a virtual address, it looks up in the TLB first to check if there is a cache hit before it passing the virtual address into the page table to translate into a physical address. For instance, if there is a TLB cache hit when people try to access a certain address in virtual memory, it only takes about 1 CPU clock cycle to access data in RAM. However, if it is a cache miss in TLB, the CPU is forced to go through the page table mapping again to find the physical address, which may take 10~100 CPU clock cycles. Apparently, when KPTI does the swap between user and kernel space page table and TLB is cleared, there can be no cache hit on each memory access. In other words, KPTI slows down the processor memory access process at least 10 times than processor with Meltdown vulnerability.
People put an experiment on the impact of the KPTI patch. The experiment mainly compares the time of the CPU spent in kernel mode and user mode. The program the CPU working on is fairly easy. It is just a loop that makes a simple system call in the middle. Here is the result:
As you can see, the average time CPU spent in kernel mode is 36.671 before the patch and 39.358 after the KPTI patch. It is clear that the processor spends about (39.358-36.671)/36.671=7.32% more time in the kernel mode. In other words, the processor has less time to process the code people offer it. Plus the TLB issue we mentioned above, the CPU can be slowed down significantly. The worst scenario in this experiment would be the processor needs to access a huge amount of data in the memory while there are many system calls in the same loop. In this case, the TLB will be flushed over and over again and CPU needs to use the page table to map to the physical address repeatedly.
Fortunately, modern CPUs that have the so-called ‘PCID’ feature can mitigate this issue to some extent because they can use this feature – which tags page table entries so the process associated with them can be retrieved efficiently – to avoid flushing the entire TLB on each mode transition.
The same group of people made another experiment to test the KPTI patch's impact on the I/O performance. They used several disk benchmarking tools to examine the effect of the patch on disk I/O (Crystal, Atto, and IOMeter) and they used a very fast SSD to test the experiment. Slower disks have limits on the system calls due to its speed, so they chose an extremely fast disk will maximize the impact of KPTI on I/O. The result shows that even though the sequential read is not affected at all, the random read (multi-thread 4K read) was slowed down from 10% to 15%.
After all, should people patch the Meltdown with the KPTI patch or not? There are different answers to different cases. According to Microsoft, database server not running in a multi-tenanted environment, (e.g on bare metal or as a guest where the other guests are also trusted) may not need patching. While web servers may be more complicated. You cannot be sure who is accessing the server in most cases, so you will probably have no option but to patch it. However, web servers can make significant I/O and network demands and may experience performance slowdowns as a result.
Reference
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
https://databricks.com/blog/2018/01/16/meltdown-and-spectre-exploits-and-mitigation-strategies.html
https://www.1e.com/news-insights/blogs/predicting-meltdown/
Before the KPTI mitigation, user and kernel modes are actually sharing the same page table. Based on people’s original assumption, user mode can not access information in kernel memory (arrow 1). However, Meltdown proves people wrong. It turns out that with the help of out-of-order execution, people can actually access that sensitive information in kernel memory, applying Meltdown(arrow 2).
This is the place where KPTI comes to assist.KPTI helps to restore the assumption we mentioned above. This mitigation gives each application two sets of pages tables rather than one and switches between them on every kernel-to-user and user-to-kernel transition. In other words, KPTI separate user-space and kernel-space memory entirely. Thus, when attackers try to access the data in the kernel memory in user mode, they can not use the user-mode page table to point to the kernel memory, since those can only be accessed by using kernel-mode page table, which can not be pulled up in user mode.
However, KPTI comes with pros and cons. Because of the separation of page table, page table swap happens on each system call, interruption and exception, and these swaps may have some impact on the performance of the processors. Even though there are only few extra instructions on each swap, the translation lookaside buffer (TLB) is cleared each time. The TLB is a cache that stores the virtual and physical memory pairings. When the processor tries to access data in a virtual address, it looks up in the TLB first to check if there is a cache hit before it passing the virtual address into the page table to translate into a physical address. For instance, if there is a TLB cache hit when people try to access a certain address in virtual memory, it only takes about 1 CPU clock cycle to access data in RAM. However, if it is a cache miss in TLB, the CPU is forced to go through the page table mapping again to find the physical address, which may take 10~100 CPU clock cycles. Apparently, when KPTI does the swap between user and kernel space page table and TLB is cleared, there can be no cache hit on each memory access. In other words, KPTI slows down the processor memory access process at least 10 times than processor with Meltdown vulnerability.
Fortunately, modern CPUs that have the so-called ‘PCID’ feature can mitigate this issue to some extent because they can use this feature – which tags page table entries so the process associated with them can be retrieved efficiently – to avoid flushing the entire TLB on each mode transition.
The same group of people made another experiment to test the KPTI patch's impact on the I/O performance. They used several disk benchmarking tools to examine the effect of the patch on disk I/O (Crystal, Atto, and IOMeter) and they used a very fast SSD to test the experiment. Slower disks have limits on the system calls due to its speed, so they chose an extremely fast disk will maximize the impact of KPTI on I/O. The result shows that even though the sequential read is not affected at all, the random read (multi-thread 4K read) was slowed down from 10% to 15%.
After all, should people patch the Meltdown with the KPTI patch or not? There are different answers to different cases. According to Microsoft, database server not running in a multi-tenanted environment, (e.g on bare metal or as a guest where the other guests are also trusted) may not need patching. While web servers may be more complicated. You cannot be sure who is accessing the server in most cases, so you will probably have no option but to patch it. However, web servers can make significant I/O and network demands and may experience performance slowdowns as a result.
Reference
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
https://databricks.com/blog/2018/01/16/meltdown-and-spectre-exploits-and-mitigation-strategies.html
https://www.1e.com/news-insights/blogs/predicting-meltdown/
Comments
Post a Comment