Defending Against ret2dir Attacks (partially) with Virtualization Technology?

I was so excited when recently reading the paper (ret2dir: Rethinking Kernel Isolation) from Vasileios P. Kemerlis. This post is basically going to introduce the idea of ret2dir attack, and how to prevent such an attack with hardware virtualization technology, actually partially. 


ret2dir (Return-to-Direct-Mapped-Memory) attack abuses physmap design in kernel virtual memory management system of many Linux/Unix OSs, it can bypass the SMEP/SMAP, PXN, KERNEXEC/UDEREF. 

So, what is physmap? 

It is Address Aliasing technique, which is designed for performance improvement. According to the author, "Given the existence of physmap, whenever the kernel (buddy allocator) maps a page frame to user space, it effectively creates an alias ( synonym) of user content in kernel space!"

To be more specific, the key point is that for the same physical memory address space in physmap region, there might have two virtual address addresses that will be translated or mapped to the same physical memory space, aka, N:1 mapping, here N is 2. One virtual address is in kernel address space (Page table U/S bit =0), and the other is in user address space (U/S=1). See picture below from ret2dir paper.

In order to make this kind of attacks work, the paper presents several innovative solutions. For example, how to force user memory allocation physical pages emerge in physmap area, how to get PFN info through information leak, and how to do physmap spaying (Can TSX help x-spaying exploit writing?) , etc. 

Besides, the author also innovates a solution in Linux kernel to mitigate this ret2dir attack: eXclusive Page Frame Ownerwhip (XPFO). 

The basic idea is very straightforward, it enforces exclusive ownership (of page frames) by either the kernel or userland unless explicitly requested by a kernel component(e.g., to implement zero-copy shared buffers). It means whenever a page frame is allocated to userland, it unmaps it from physmap; when such a page frame is reclaimed from userland, it puts it back to physmap. 

In a virtualization environment, however, this solution (How to Implement a software-based SMEP with Virtualization/Hypervisor Technology) in my previous post may be able to stop or defend against ret2dir attacks. But it also has a limitation: the virtualization-based software SMEP can only stop execution of shellcode/payload in physmem area.

In order to stop read/write access to payload from kernel space with ret2dir attacks (which could be used to do ROP attacks, e.g. use the payload as kernel stack after stack pivoting), technically, we can extend that solution to implement a virtualization-based software SMAP to defend against ret2dir attacks... 


References:
ret2dir: Rethinking Kernel Isolation -- paper:
http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf

and its slides:
https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf

OpenBSD fix to remove executable permission in direct-map pages (recently): 

https://secure.freshbsd.org/commit/openbsd/52e8e9f52ef21a21a315187623fafe4800efd868