"Like most mainstream operating systems, the vanilla Linux kernel does not leverage x86 segmentation, instead defining flat segment descriptors with limits encompassing the entire 4gb address space. Additionally, each process has the kernel’s page table entries replicated, resulting in the kernel address space being mapped in the upper 1gb of every user process. (...) The result of this is that the kernel is free to incorrectly access data residing in userspace, as well as execute code in the user region. In addition to enabling the exploitation of many bugs that rely on the kernel incorrectly using user data, this allows kernel exploits to simply map a suitable payload in userspace and divert kernel execution to that payload. (...)
The PaX project solves this problem in a general way with a feature called PAX_UDEREF. When this feature is enabled, PaX leverages segmentation to isolate user and kernel addresses, such that a fault will be generated when the kernel incorrectly accesses user data or code. Unfortunately, due to the performance hit associated with reloading segment registers and the fact that this touches mission-critical code, it’s unlikely that this solution would be accepted into the upstream Linux kernel. (...)
Enter SMEP. Now, the mainline Linux kernel can take advantage of a subset of this protection at essentially no performance cost, as the functionality is presumably implemented in hardware in a way that’s similar to existing CPL checks. With SMEP enabled, it’s no longer possible to map exploit payloads in userland, as the CPU will trigger a fault if it attempts to execute those user pages in kernel mode. Note that this is still only a subset of what UDEREF protects against, as it does nothing to prevent the kernel from incorrectly accessing user *data* as opposed to code. But it’s certainly a start."
Artigo completo: SMEP: What is It, and How to Beat It on Linux