From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:50411)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RSaic-00055E-8p
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:44:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RSaiW-0006jX-6p
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:43:58 -0500
Received: from mail-gy0-f173.google.com ([209.85.160.173]:43790)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1RSaiW-0006jP-3v
	for qemu-devel@nongnu.org; Mon, 21 Nov 2011 15:43:52 -0500
Received: by ghbg19 with SMTP id g19so2811900ghb.4
	for <qemu-devel@nongnu.org>; Mon, 21 Nov 2011 12:43:50 -0800 (PST)
Message-ID: <4ECAB801.5090708@codemonkey.ws>
Date: Mon, 21 Nov 2011 14:43:45 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <87aa7pfosp.fsf@neno.neno>
In-Reply-To: <87aa7pfosp.fsf@neno.neno>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] KVM call agenda for Novemeber 22
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: quintela@redhat.com
Cc: Developers qemu-devel <qemu-devel@nongnu.org>, KVM devel mailing list <kvm@vger.kernel.org>

On 11/21/2011 10:00 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.

I'm technical on holiday this week so I won't be attending.

But as an FYI, I ran across seccomp-nurse[1] this weekend.  It more or less 
let's you write a python program to implement a userspace syscall whitelist.

I haven't looked at the code close enough yet, but I think the technique it uses 
is to create a companion thread along side the sandbox thread.  This thread only 
runs code in an area mapped read-only and presumably only uses thread local storage.

The companion thread isn't running in the sandbox, but has the same resources as 
the sandbox thread so it can essentially invoke syscalls on behalf of the 
sandbox thread.

It's seriously non-portable.  In fact, it only works on 32-bit x86 Linux right 
now.  But it's worth looking into.

[1] http://chdir.org/~nico/seccomp-nurse/

Regards,

Anthony Liguori

>
> Later, Juan.
>