Industry-wide severity ratings can be found in the National Vulnerability Database
This method involves an application (user) attacker directly probing kernel (supervisor) memory. Such an operation typically results in a program error (page fault due to page table permissions). However, it is possible for such an operation to be speculatively executed under certain conditions for certain implementations. For instance, on some implementations speculatively probing memory will only pass data on to subsequent operations if the data is resident in the lowest level data cache (L1). This can allow the data in question to be queried by the malicious application, leading to a side channel that reveals supervisor data. This method only applies to regions of memory designated supervisor-only by the page tables, not memory designated as not present.
For this method, the operating system software may ensure that privileged pages are not mapped when executing user code to prevent user mode from accessing privileged pages. The OS can establish two paging structure roots (CR3 values) for each user process:
This basic dual-page-table approach was previously proposed as a mitigation for side channel attacks on Kernel Address Space Layout Randomization (KASLR) in the “KASLR is Dead: Long Live KASLR” paper and was called KAISER. This approach also mitigates Rogue Data Cache Load. Intel has worked with various OS vendors to enable a dual-page-table approach in their operating systems.
The Process Context Identifier (PCID) is a processor feature that can greatly reduce the performance cost of TLB flushes caused by frequent reloading of CR3 during user/supervisor mode transitions. OSes can take advantage of this feature on processors that support PCID.
Future Intel processors will also have hardware support for mitigating Rogue Data Cache Load.
Rogue data cache load exploit targets a processor’s speculative data loading mechanisms. Even though the processor’s access control may protect a piece of data, it may still be read speculatively before an illegal access is determined to exist. The rogue data cache load exploit occurs entirely within code which is under the control of an attacker. This means we cannot modify the kernel to mitigate this exploit—we must fundamentally change where kernel data is available. The mitigation for this is conceptually very simple: instead of relying on a processor’s access-control mechanisms to protect data, simply remove the data instead.
In Linux*, this mitigation is referred to as Kernel Page Table Isolation (KPTI). This mitigation removes the data from the reach of exploits by having the kernel maintain two independent copies of the hardware page tables. One copy contains the minimal set of data and code needed to run an application and enter or exit the kernel, but it does not contain valuable kernel data. This helps ensure no valuable data can be leaked by an exploit running outside the kernel. The other set of page tables, active only while the kernel is running, contains everything needed for the kernel to function normally, including its private data.