linux-kernel - Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

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: <20080205080149.GA16929@elte.hu>
Date:	Tue, 5 Feb 2008 09:01:49 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Roland McGrath <roland@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user
	space


* Roland McGrath <roland@...hat.com> wrote:

> This makes the x86-64 behavior for 32-bit processes that set bogus 
> %cs/%ss values (the only ones that can fault in iret) match what the 
> native i386 behavior has been since:
> 
> 	commit a879cbbb34cbecfa9707fbb6e5a00c503ac1ecb9
> 	Author: Linus Torvalds <torvalds@...970.osdl.org>
> 	Date:   Fri Apr 29 09:38:44 2005 -0700
> 
> 	    x86: make traps on 'iret' be debuggable in user space
> 
> Signed-off-by: Roland McGrath <roland@...hat.com>
> ---
>  arch/x86/kernel/entry_64.S |   25 +++++++++++++++++++------
>  1 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 07d4aba..62744b1 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -592,13 +592,26 @@ ENTRY(native_iret)
>  	.quad native_iret, bad_iret
>  	.previous
>  	.section .fixup,"ax"
> -	/* force a signal here? this matches i386 behaviour */
> -	/* running with kernel gs */
>  bad_iret:
> -	movq $11,%rdi	/* SIGSEGV */
> -	TRACE_IRQS_ON
> -	ENABLE_INTERRUPTS(CLBR_ANY | ~(CLBR_RDI))
> -	jmp do_exit
> +	/*
> +	 * The iret traps when the %cs or %ss being restored is bogus.
> +	 * (This can only happen in a 32-bit process, and only by invalid
> +	 * selectors being set via ptrace.  Changing the value enforces
> +	 * that the USER_RPL bits are set, but not that the index is valid.)
> +	 * We've lost the original trap vector and error code.
> +	 * #GPF is the most likely one to get for an invalid selector.
> +	 * So pretend we completed the iret and took the #GPF in user mode.
> +	 *
> +	 * We are now running with the kernel GS after exception recovery.
> +	 * But error_entry expects us to have user GS to match the user %cs,
> +	 * so swap back.
> +	 */
> +	INTR_FRAME
> +	pushq $0
> +	CFI_ADJUST_CFA_OFFSET 8
> +	SWAPGS
> +	jmp general_protection
> +	CFI_ENDPROC
>  	.previous

thanks, applied. I suppose you have a testcase for this that we could 
try?

	Ingo
--
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/