From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:59711)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <panda23@hush.ai>) id 1Rbv9U-0008A0-57
	for qemu-devel@nongnu.org; Sat, 17 Dec 2011 09:22:16 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <panda23@hush.ai>) id 1Rbv9S-0004nd-W4
	for qemu-devel@nongnu.org; Sat, 17 Dec 2011 09:22:16 -0500
Received: from smtp1.hushmail.com ([65.39.178.133]:35117
	helo=smtp11.hushmail.com) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <panda23@hush.ai>) id 1Rbv9S-0004n2-Rs
	for qemu-devel@nongnu.org; Sat, 17 Dec 2011 09:22:14 -0500
Received: from smtp11.hushmail.com (localhost.localdomain [127.0.0.1])
	by smtp11.hushmail.com (Postfix) with SMTP id C50BF1CAA58
	for <qemu-devel@nongnu.org>; Sat, 17 Dec 2011 14:22:12 +0000 (UTC)
Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80])
	by smtp11.hushmail.com (Postfix) with ESMTP
	for <qemu-devel@nongnu.org>; Sat, 17 Dec 2011 14:22:12 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 17 Dec 2011 14:22:12 +0000
From: panda23@hush.ai
Content-Type: multipart/alternative;
	boundary="=_f36f245d4e241e2cbc5b15f7a4b442cd"
Message-Id: <20111217142212.5E019E6736@smtp.hushmail.com>
Subject: [Qemu-devel] Changing vmexit behavior for a running guest
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

--=_f36f245d4e241e2cbc5b15f7a4b442cd
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"

For sandboxing some forms of untrusted code, the risk of a red pill
could be greatly reduced if qemu had "seccomp" mode, i.e., a way for a
guest OS to request that qemu drop any future unwhitelisted vmexit
calls.  How complicated would it be to add this functionality to qemu
and which parts of qemu would I need to modify?

Jason


--=_f36f245d4e241e2cbc5b15f7a4b442cd
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<span style=3D"font-family: Arial; font-size: 13px;">For sandboxing some fo=
rms of untrusted code, the risk of a red pill could be greatly reduced if q=
emu had "seccomp" mode, i.e., a way for a guest OS to request that qemu dro=
p any future unwhitelisted vmexit calls.&nbsp; How complicated would it be =
to add this functionality to qemu and which parts of qemu would I need to m=
odify?<br><br>Jason<br><br></span>
--=_f36f245d4e241e2cbc5b15f7a4b442cd--