Meltdown-type attacks are still feasible in the wall of kernel page-Table isolation

Abstract

Meltdown released in 2018 is a hardware vulnerability primarily affecting Intel modern processors. It allows a rogue process to read the kernel data in CPU L1D cache. To defend against the Meltdown attack in legacy processors, the most effective software-only mitigation approach is to unmap kernel memory from user processes, known as kernel page-table isolation (KPTI).In this paper, we present a novel Meltdown-type attack, named KPTImew, that can defeat KPTI in Linux and reliably dump all the target data in the kernel address space. We observe that there still exists kernel memory mapped in a user process, indicating that the mapped memory content can still be leaked through the Meltdown attack. However, the Meltdown attack is limited to leaking data that must be resident in CPU L1D cache. To lift the limitation, we propose a new technique, called reDump, as a part of our contribution. reDump exploits speculative execution to load data in the mapped memory into L1D cache and thus reliably dump the data using the Meltdown attack. To further leak data from the whole kernel including the above mapped memory, KPTImew first establishes data dependency between the mapped memory and any target kernel memory, and then exploits the data dependency to bring certain mapped kernel data into L1D cache that is dependent on targeted kernel data. When the mapped kernel data is leaked, the targeted kernel data can be leaked through the data-dependency.We modify an open-source tool, called smatch, to find such gadgets in recent kernels (i.e., 4.17.3 and 5.8.7) for loading the kernel mapped data into L1D cache and establishing the data-dependency, respectively. Specifically, dozens of potential gadgets are found in default kernel compile configuration while hundreds of gadget candidates are available for all-yes compile configuration. Our experiments show that reDump leaks 32 B of the mapped data within 6 seconds on average. With the assistance of reDump, KPTImew leaks any 32 B of kernel data within 12 seconds on average. In comparison, KPTImew can also work independently and requires 218 seconds on average to leak 32 B without reDump.