From: Ingo Molnar <mingo@elte.hu>
To: Roland McGrath <roland@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space
Date: Tue, 5 Feb 2008 09:01:49 +0100 [thread overview]
Message-ID: <20080205080149.GA16929@elte.hu> (raw)
In-Reply-To: <20080205075137.617012701A8@magilla.localdomain>
* 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
next prev parent reply other threads:[~2008-02-05 8:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 7:51 [PATCH] x86_64: make traps on 'iret' be debuggable in user space Roland McGrath
2008-02-05 8:01 ` Ingo Molnar [this message]
2008-02-05 8:15 ` Roland McGrath
2008-02-05 8:16 ` Roland McGrath
2008-02-07 20:13 ` Chuck Ebbert
2008-02-07 20:30 ` Roland McGrath
2008-02-07 23:28 ` Chuck Ebbert
2008-02-08 0:00 ` Roland McGrath
2008-02-08 0:06 ` Chuck Ebbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080205080149.GA16929@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.