[PATCH] x86: be more helpful with SMEP faults

[Jiri Kosina]

If pagefault happens due to SMEP triggering, it can't be really easily 
distinguished from any other oops-causing pagefault, which might lead to 
quite some confusion when trying to understand the reason for the oops.

Print an explanatory message in case the fault happened during instruction 
fetch for _PAGE_USER page which is present and executable on SMEP-enabled 
CPUs.

This is consistent with what we are doing for NX already; in addition to 
immediately seeing from the oops what might be happening, it can even 
easily give a good indication to sysadmins who are carefully monitoring 
their kernel logs that someone might be trying to pwn them.

Tested-by: Libor Pechacek <lpechacek@xxxxxxx>
Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
---
 arch/x86/mm/fault.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 8e57229..2466ced 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -574,6 +574,8 @@ static int is_f00f_bug(struct pt_regs *regs, unsigned long address)
 
 static const char nx_warning[] = KERN_CRIT
 "kernel tried to execute NX-protected page - exploit attempt? (uid: %d)\n";
+static const char smep_warning[] = KERN_CRIT
+"unable to execute userspace code (SMEP?) (uid: %d)\n";
 
 static void
 show_fault_oops(struct pt_regs *regs, unsigned long error_code,
@@ -594,6 +596,11 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code,
 
 		if (pte && pte_present(*pte) && !pte_exec(*pte))
 			printk(nx_warning, from_kuid(&init_user_ns, current_uid()));
+		if (pte && pte_present(*pte) && pte_exec(*pte) &&
+				(pgd_flags(*pgd) & _PAGE_USER) &&
+				static_cpu_has(X86_FEATURE_SMEP) &&
+				(read_cr4() & X86_CR4_SMEP))
+			printk(smep_warning, from_kuid(&init_user_ns, current_uid()));
 	}
 
 	printk(KERN_ALERT "BUG: unable to handle kernel ");

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/