All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86: be more helpful with SMEP faults
@ 2014-06-10 19:08 Jiri Kosina
  2014-06-10 20:18 ` Borislav Petkov
  0 siblings, 1 reply; 5+ messages in thread
From: Jiri Kosina @ 2014-06-10 19:08 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin
  Cc: x86, linux-kernel, bpetkov, jroedel

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@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.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) &&
+				(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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] x86: be more helpful with SMEP faults
  2014-06-10 19:08 [PATCH] x86: be more helpful with SMEP faults Jiri Kosina
@ 2014-06-10 20:18 ` Borislav Petkov
  2014-06-10 20:24   ` H. Peter Anvin
  0 siblings, 1 reply; 5+ messages in thread
From: Borislav Petkov @ 2014-06-10 20:18 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, linux-kernel, jroedel

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@suse.cz>
> Signed-off-by: Jiri Kosina <jkosina@suse.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.
--

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] x86: be more helpful with SMEP faults
  2014-06-10 20:18 ` Borislav Petkov
@ 2014-06-10 20:24   ` H. Peter Anvin
  2014-06-10 20:49     ` Jiri Kosina
  0 siblings, 1 reply; 5+ messages in thread
From: H. Peter Anvin @ 2014-06-10 20:24 UTC (permalink / raw)
  To: Borislav Petkov, Jiri Kosina
  Cc: Thomas Gleixner, Ingo Molnar, x86, linux-kernel, jroedel

On 06/10/2014 01:18 PM, Borislav Petkov wrote:
>>  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?
> 

Yes.  Also, the Linux kernel will set or clear X86_FEATURE_SMEP to
match, so the two are redundant.

	-hpa



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] x86: be more helpful with SMEP faults
  2014-06-10 20:24   ` H. Peter Anvin
@ 2014-06-10 20:49     ` Jiri Kosina
  2014-06-12  0:58       ` [tip:x86/mm] x86/smep: Be more informative when signalling an SMEP fault tip-bot for Jiri Kosina
  0 siblings, 1 reply; 5+ messages in thread
From: Jiri Kosina @ 2014-06-10 20:49 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Borislav Petkov, Thomas Gleixner, Ingo Molnar, x86, linux-kernel,
	jroedel

On Tue, 10 Jun 2014, H. Peter Anvin wrote:

> >> @@ -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?
> 
> Yes.  Also, the Linux kernel will set or clear X86_FEATURE_SMEP to
> match, so the two are redundant.




From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH v2] x86: be more helpful with SMEP faults

If pagefault triggers 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.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
 arch/x86/mm/fault.c | 6 ++++++
 1 file changed, 6 insertions(+)

- v1 -> v2: removed redundant X86_FEATURE_SMEP check

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 8e57229..6f6b0e8 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,10 @@ 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) &&
+				(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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [tip:x86/mm] x86/smep: Be more informative when signalling an SMEP fault
  2014-06-10 20:49     ` Jiri Kosina
@ 2014-06-12  0:58       ` tip-bot for Jiri Kosina
  0 siblings, 0 replies; 5+ messages in thread
From: tip-bot for Jiri Kosina @ 2014-06-12  0:58 UTC (permalink / raw)
  To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, jkosina, tglx, hpa

Commit-ID:  eff50c347fcc8feeb8c1723c23c89aba67c60263
Gitweb:     http://git.kernel.org/tip/eff50c347fcc8feeb8c1723c23c89aba67c60263
Author:     Jiri Kosina <jkosina@suse.cz>
AuthorDate: Tue, 10 Jun 2014 22:49:31 +0200
Committer:  H. Peter Anvin <hpa@linux.intel.com>
CommitDate: Wed, 11 Jun 2014 17:55:30 -0700

x86/smep: Be more informative when signalling an SMEP fault

If pagefault triggers 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.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1406102248490.1321@pobox.suse.cz
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
---
 arch/x86/mm/fault.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 858b47b..9de4cdb 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -575,6 +575,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,
@@ -595,6 +597,10 @@ 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) &&
+				(read_cr4() & X86_CR4_SMEP))
+			printk(smep_warning, from_kuid(&init_user_ns, current_uid()));
 	}
 
 	printk(KERN_ALERT "BUG: unable to handle kernel ");

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-06-12  0:58 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-10 19:08 [PATCH] x86: be more helpful with SMEP faults Jiri Kosina
2014-06-10 20:18 ` Borislav Petkov
2014-06-10 20:24   ` H. Peter Anvin
2014-06-10 20:49     ` Jiri Kosina
2014-06-12  0:58       ` [tip:x86/mm] x86/smep: Be more informative when signalling an SMEP fault tip-bot for Jiri Kosina

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.