[PATCH] x86_64: make traps on 'iret' be debuggable in user space

[PATCH] x86_64: make traps on 'iret' be debuggable in user space

[Roland McGrath]

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@ppc970.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@redhat.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
 
 	/* edi: workmask, edx: work */

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

[Ingo Molnar]

* Roland McGrath <roland@redhat.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@ppc970.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@redhat.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

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

[Roland McGrath]

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

This should exit 0 and show "wait status 0xb7f", and does on i386.
On 2.6.24 it exits 1 and shows "wait status 0xb".

Note, on the current tree before [PATCH] x86_64: fix iret exception recovery
that I also posted today, this will instead produce pathological weirdness
probably with a quick crash or silent reboot, from running with the wrong GS.

Thanks,
Roland

---
#define _GNU_SOURCE
#include <assert.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <stddef.h>
#include <sys/ptrace.h>
#include <asm/ptrace.h>
#include <asm/user.h>

static pid_t child;

static void
cleanup (void)
{
  if (child != 0)
    kill (child, SIGKILL);
}

static void
handler_fail (int signo)
{
  cleanup ();

  signal (SIGABRT, SIG_DFL);
  abort ();
}

int main (void)
{
  long l;
  int status, i;
  pid_t pid;
  long cs;

  setbuf (stdout, NULL);
  atexit (cleanup);
  signal (SIGABRT, handler_fail);
  signal (SIGINT, handler_fail);
  signal (SIGALRM, handler_fail);
  alarm (10);

  signal (SIGUSR1, SIG_IGN);
  signal (SIGUSR2, SIG_IGN);

  child = fork ();
  switch (child)
    {
    case -1:
      assert_perror (errno);
      assert (0);
    case 0:
      l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
      assert (l == 0);
      i = raise (SIGUSR1);
      assert (i == 0);
      assert (0);
    default:
      break;
    }

  pid = waitpid (child, &status, 0);
  assert (pid == child);
  assert (WIFSTOPPED (status));
  assert (WSTOPSIG (status) == SIGUSR1);

  cs = 0xFFFF;

  l = ptrace (PTRACE_POKEUSER, child,
	      (void *) offsetof (struct user_regs_struct, cs), (void *) cs);
  assert (l == 0);

  l = ptrace (PTRACE_CONT, child, NULL, NULL);
  assert (l == 0);

  pid = waitpid (child, &status, 0);
  assert (pid == child);

  printf ("wait status %#x\n", status);

  return WIFSTOPPED (status) ? 0 : 1;
}

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

[Roland McGrath]

> > thanks, applied. I suppose you have a testcase for this that we could try?
> 
> This should exit 0 and show "wait status 0xb7f", and does on i386.
> On 2.6.24 it exits 1 and shows "wait status 0xb".

To clarify, build the case with -m32 but run on x86_64.


Thanks,
Roland

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

[Chuck Ebbert]

On 02/05/2008 03:15 AM, Roland McGrath wrote:
>> thanks, applied. I suppose you have a testcase for this that we could try?
> 
> This should exit 0 and show "wait status 0xb7f", and does on i386.
> On 2.6.24 it exits 1 and shows "wait status 0xb".
> 
> Note, on the current tree before [PATCH] x86_64: fix iret exception recovery
> that I also posted today, this will instead produce pathological weirdness
> probably with a quick crash or silent reboot, from running with the wrong GS.
> 

Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
without the "noreplace-paravirt" parameter?

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

[Roland McGrath]

> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
> without the "noreplace-paravirt" parameter?

I did not test CONFIG_PARAVIRT at all.  I just fixed what its introduction
had done to break generic x86-64.


Thanks,
Roland

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

[Chuck Ebbert]

On 02/07/2008 03:30 PM, Roland McGrath wrote:
>> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
>> without the "noreplace-paravirt" parameter?
> 
> I did not test CONFIG_PARAVIRT at all.  I just fixed what its introduction
> had done to break generic x86-64.
> 
> 

It looks you may have broken paravirt (if even that case worked) because
the iret is actually at the iret_label you removed (after the instruction
is patched.) And most likely neither version worked with "noreplace-paravirt',
because then the iret instruction is out-of-line and the INTERRUPT_RETURN
jumps to it.

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

[Roland McGrath]

It sure didn't look to me like paravirt probably worked.  But what do I know?

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

[Chuck Ebbert]

On 02/07/2008 07:00 PM, Roland McGrath wrote:
> It sure didn't look to me like paravirt probably worked.  But what do I know?
> 

I said "if" it worked you probably would have broken it. :)