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 <[email protected]>
Date: Fri Apr 29 09:38:44 2005 -0700
x86: make traps on 'iret' be debuggable in user space
Signed-off-by: Roland McGrath <[email protected]>
---
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 */
* Roland McGrath <[email protected]> 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 <[email protected]>
> Date: Fri Apr 29 09:38:44 2005 -0700
>
> x86: make traps on 'iret' be debuggable in user space
>
> Signed-off-by: Roland McGrath <[email protected]>
> ---
> 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
> 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;
}
> > 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
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?
> 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
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.
It sure didn't look to me like paravirt probably worked. But what do I know?
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. :)