Re: [PATCH] x86: be more helpful with SMEP faults

[Borislav Petkov]

On Tue, Jun 10, 2014 at 09:08:21PM +0200, Jiri Kosina wrote:
> 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) &&

Btw, we could probably save us this line as CR4 reserved bits should be
Must-Be-Zero and setting any of those should #GP. And I'm talking about
pre-SMEP Intel, and AMD machines.

IOW, if CR4.SMEP is set, it definitely means SMEP is present and
enabled.

hpa, that true?

> +				(read_cr4() & X86_CR4_SMEP))
> +			printk(smep_warning, from_kuid(&init_user_ns, current_uid()));
>  	}

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/