xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, WeiLiu <wl@xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] x86/traps: guard top-of-stack reads
Date: Mon, 17 Jun 2019 02:12:47 -0600	[thread overview]
Message-ID: <5D074B7F0200007800238B69@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <5D074AE60200007800238B5E@prv1-mh.provo.novell.com>

Nothing (afaics) guarantees that the original frame's stack pointer
points at readable memory. Avoid a (likely nested) crash by attaching
exception recovery to the read (making it a single read at the same
time). Don't even invoke _show_trace() in case of a non-readable top
slot.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Name asm() arguments. Use explicit "fault" variable.

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -484,17 +484,31 @@ static void _show_trace(unsigned long sp
 
 static void show_trace(const struct cpu_user_regs *regs)
 {
-    unsigned long *sp = ESP_BEFORE_EXCEPTION(regs);
+    unsigned long *sp = ESP_BEFORE_EXCEPTION(regs), tos = 0;
+    bool fault = false;
 
     printk("Xen call trace:\n");
 
+    /* Guarded read of the stack top. */
+    asm ( "1: mov %[data], %[tos]; 2:\n"
+          ".pushsection .fixup,\"ax\"\n"
+          "3: movb $1, %[fault]; jmp 2b\n"
+          ".popsection\n"
+          _ASM_EXTABLE(1b, 3b)
+          : [tos] "+r" (tos), [fault] "+qm" (fault) : [data] "m" (*sp) );
+
     /*
      * If RIP looks sensible, or the top of the stack doesn't, print RIP at
      * the top of the stack trace.
      */
     if ( is_active_kernel_text(regs->rip) ||
-         !is_active_kernel_text(*sp) )
+         !is_active_kernel_text(tos) )
         printk("   [<%p>] %pS\n", _p(regs->rip), _p(regs->rip));
+    else if ( fault )
+    {
+        printk("   [Fault on access]\n");
+        return;
+    }
     /*
      * Else RIP looks bad but the top of the stack looks good.  Perhaps we
      * followed a wild function pointer? Lets assume the top of the stack is a
@@ -503,7 +517,7 @@ static void show_trace(const struct cpu_
      */
     else
     {
-        printk("   [<%p>] %pS\n", _p(*sp), _p(*sp));
+        printk("   [<%p>] %pS\n", _p(tos), _p(tos));
         sp++;
     }
 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-06-17  8:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31  8:59 [PATCH 0/2]: x86/traps: improve show_trace()'s top-of-stack handling Jan Beulich
2019-05-31  8:59 ` [Xen-devel] " Jan Beulich
2019-05-31  9:17 ` [PATCH 1/2] x86/traps: guard top-of-stack reads Jan Beulich
2019-05-31  9:17   ` [Xen-devel] " Jan Beulich
2019-06-07 17:51   ` Andrew Cooper
2019-06-11  9:57     ` Jan Beulich
2019-05-31  9:22 ` [PATCH 2/2] x86/traps: widen condition for logging top-of-stack Jan Beulich
2019-05-31  9:22   ` [Xen-devel] " Jan Beulich
2019-06-07 18:01   ` Andrew Cooper
2019-06-11  9:46     ` Jan Beulich
2019-06-17  8:10 ` [Xen-devel] [PATCH v2 0/2]: x86/traps: improve show_trace()'s top-of-stack handling Jan Beulich
2019-06-17  8:12   ` Jan Beulich [this message]
2019-07-02 17:47     ` [Xen-devel] [PATCH v2 1/2] x86/traps: guard top-of-stack reads Andrew Cooper
2019-07-03  7:10       ` Jan Beulich
2019-06-17  8:13   ` [Xen-devel] [PATCH v2 2/2] x86/traps: widen condition for logging top-of-stack Jan Beulich
2019-07-03 10:21     ` Andrew Cooper
2019-07-03 10:34       ` Jan Beulich
2019-07-03 19:47         ` Andrew Cooper
2019-07-04  9:09           ` Jan Beulich

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=5D074B7F0200007800238B69@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).