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 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to