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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140610201823.GA29302@pd.tnic>
Date:	Tue, 10 Jun 2014 22:18:23 +0200
From:	Borislav Petkov <bp@...e.de>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, jroedel@...e.de
Subject: Re: [PATCH] x86: be more helpful with SMEP faults

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@...e.cz>
> Signed-off-by: Jiri Kosina <jkosina@...e.cz>
> ---
>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/