linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Zachary Amsden <zamsden@redhat.com>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, avi@redhat.com,
	mtosatti@redhat.com
Subject: Re: use of setjmp/longjmp in x86 emulator.
Date: Tue, 2 Mar 2010 10:49:07 +0200	[thread overview]
Message-ID: <20100302084907.GV16909@redhat.com> (raw)
In-Reply-To: <4B8C463B.7070900@zytor.com>

On Mon, Mar 01, 2010 at 02:56:59PM -0800, H. Peter Anvin wrote:
> On 03/01/2010 02:31 PM, H. Peter Anvin wrote:
> > On 03/01/2010 11:18 AM, Zachary Amsden wrote:
> >>
> >> It's going to be ugly to emulate segmentation, NX and write protect 
> >> support without hardware to do this checking for you, but it's just what 
> >> you have to do in this slow path - tedious, fully specified emulation.
> >>
> >> Just because it's tedious doesn't mean we need to use setjmp / longjmp.  
> >> Throw / catch might be effective, but it's still pretty bizarre to do 
> >> tricks like that in C.
> >>
> > 
> > Well, setjmp/longjmp really is not much more than exception handling in C.
> > 
> 
> For what it's worth, I think that setjmp/longjmp is not anywhere near as
> dangerous as people want to make it out to be.  gcc will warn for
> dangerous uses (and a lot of non-dangerous uses), but generally the
> difficult problems can be dealt with by moving the setjmp-protected code
> into a separate function.
> 
Can I consider this as ACK for something like the patch blow? :) (with
proper x86 version of setjmp/longjmp of course).

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index cfcb6f0..089a405 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -35,6 +35,45 @@
 #include "x86.h"
 #include "tss.h"
 
+typedef unsigned long jmp_buf[8];
+int setjmp(jmp_buf);
+void longjmp(jmp_buf, int);
+
+asm (
+"	.align 4\n"
+"	.type setjmp, @function\n"
+"setjmp:\n"
+"	pop  %rsi		# Return address, and adjust the stack\n"
+"	xorl %eax,%eax		# Return value\n"
+"	movq %rbx,(%rdi)\n"
+"	movq %rsp,8(%rdi)	# Post-return %rsp!\n"
+"	push %rsi		# Make the call/return stack happy\n"
+"	movq %rbp,16(%rdi)\n"
+"	movq %r12,24(%rdi)\n"
+"	movq %r13,32(%rdi)\n"
+"	movq %r14,40(%rdi)\n"
+"	movq %r15,48(%rdi)\n"
+"	movq %rsi,56(%rdi)	# Return address\n"
+"	ret\n"
+"	.size setjmp,.-setjmp\n"
+
+"	.align 4\n"
+"	.type longjmp, @function\n"
+"longjmp:\n"
+"	movl %esi,%eax		# Return value (int)\n"
+"	movq (%rdi),%rbx\n"
+"	movq 8(%rdi),%rsp\n"
+"	movq 16(%rdi),%rbp\n"
+"	movq 24(%rdi),%r12\n"
+"	movq 32(%rdi),%r13\n"
+"	movq 40(%rdi),%r14\n"
+"	movq 48(%rdi),%r15\n"
+"	jmp *56(%rdi)\n"
+"	.size longjmp,.-longjmp\n"
+	);
+
+static jmp_buf jb;
+
 /*
  * Opcode effective-address decode tables.
  * Note that we only emulate instructions that have at least one memory
@@ -1729,7 +1768,7 @@ static inline int writeback(struct x86_emulate_ctxt *ctxt,
 					c->dst.bytes,
 					ctxt->vcpu);
 		if (rc != X86EMUL_CONTINUE)
-			return rc;
+			longjmp(jb, 1);
 		break;
 	case OP_NONE:
 		/* no writeback */
@@ -2391,6 +2430,11 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct x86_emulate_ops *ops)
 	memcpy(c->regs, ctxt->vcpu->arch.regs, sizeof c->regs);
 	saved_eip = c->eip;
 
+	if (setjmp(jb)) {
+		printk(KERN_ERR"setjump() == 1\n");
+		return 0;
+	}
+
 	if (ctxt->mode == X86EMUL_MODE_PROT64 && (c->d & No64)) {
 		kvm_queue_exception(ctxt->vcpu, UD_VECTOR);
 		goto done;
--
			Gleb.

  parent reply	other threads:[~2010-03-02  8:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-01  9:18 use of setjmp/longjmp in x86 emulator Gleb Natapov
2010-03-01 12:45 ` Takuya Yoshikawa
2010-03-01 12:52   ` Gleb Natapov
2010-03-01 13:17     ` Takuya Yoshikawa
2010-03-01 13:26       ` Gleb Natapov
2010-03-01 19:13         ` john cooper
2010-03-02  7:28           ` Gleb Natapov
2010-03-07  9:00             ` Avi Kivity
2010-03-08 23:11               ` Eric W. Biederman
2010-03-09  6:28                 ` Gleb Natapov
2010-03-01 16:13 ` Zachary Amsden
2010-03-01 17:47   ` Gleb Natapov
2010-03-01 18:39     ` Zachary Amsden
2010-03-01 18:47       ` Luca Barbieri
2010-03-01 19:03       ` Gleb Natapov
2010-03-01 19:18         ` Zachary Amsden
2010-03-01 22:31           ` H. Peter Anvin
2010-03-01 22:56             ` H. Peter Anvin
2010-03-01 23:34               ` Zachary Amsden
2010-03-01 23:43                 ` H. Peter Anvin
2010-03-02  8:05                 ` Gleb Natapov
2010-03-02  8:49               ` Gleb Natapov [this message]
2010-03-07  9:04                 ` Avi Kivity
2010-03-08  0:08                   ` H. Peter Anvin

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=20100302084907.GV16909@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=zamsden@redhat.com \
    /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).