Quoting Paul Moore (pmo...@redhat.com):
> On Thursday, December 15, 2011 09:14:11 AM Serge Hallyn wrote:
> > Quoting Corey Bryant (cor...@linux.vnet.ibm.com):
> > > On 12/14/2011 06:56 PM, Paul Moore wrote:
> > > >On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
> > > >>Hey Paul,
On Thursday, December 15, 2011 09:14:11 AM Serge Hallyn wrote:
> Quoting Corey Bryant (cor...@linux.vnet.ibm.com):
> > On 12/14/2011 06:56 PM, Paul Moore wrote:
> > >On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
> > >>Hey Paul,
> > >>
> > >>just wondering, exactly which approac
Quoting Corey Bryant (cor...@linux.vnet.ibm.com):
>
>
> On 12/14/2011 06:56 PM, Paul Moore wrote:
> >On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
> >>Quoting Paul Moore (pmo...@redhat.com):
> >>>On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
> On 12/0
On 12/14/2011 06:56 PM, Paul Moore wrote:
On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
Quoting Paul Moore (pmo...@redhat.com):
On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
On 12/07/2011 12:25 PM, Corey Bryant wrote:
A group of us are starting to w
On Wednesday, December 14, 2011 11:15:58 AM Serge E. Hallyn wrote:
> Quoting Paul Moore (pmo...@redhat.com):
> > On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
> > > On 12/07/2011 12:25 PM, Corey Bryant wrote:
> > > > A group of us are starting to work on sandboxing QEMU device
Quoting Paul Moore (pmo...@redhat.com):
> On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
> > On 12/07/2011 12:25 PM, Corey Bryant wrote:
> > > A group of us are starting to work on sandboxing QEMU device emulation
> > > code. We're just getting started investigating various appr
On Sun, Dec 11, 2011 at 4:50 AM, Dor Laor wrote:
> On 12/08/2011 11:40 AM, Stefan Hajnoczi wrote:
>>
>> On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris wrote:
>>>
>>> On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote:
On 12/07/2011 01:32 PM, Corey Bryant wrote:
>>>
>>>
> That woul
On 12/08/2011 04:51 PM, Blue Swirl wrote:
Why limit this to device emulation only? Where in QEMU would this
approach not work?
That's a good point, and we've thrown this idea around. I don't know if
there's any reason why this approach wouldn't work for all of QEMU. The
idea for now thoug
On 12/08/2011 11:40 AM, Stefan Hajnoczi wrote:
On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris wrote:
On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote:
On 12/07/2011 01:32 PM, Corey Bryant wrote:
That would seem like the logical approach. I think there may be new mode 2
patches coming so
On 12/09/2011 06:17 PM, Paul Brook wrote:
> > A group of us are starting to work on sandboxing QEMU device emulation
> > code. We're just getting started investigating various approaches, and
> > want to engage the community to gather input.
> >
> > Following are the design points that we are cur
On Fri, Dec 9, 2011 at 16:17, Paul Brook wrote:
>> A group of us are starting to work on sandboxing QEMU device emulation
>> code. We're just getting started investigating various approaches, and
>> want to engage the community to gather input.
>>
>> Following are the design points that we are cu
On Friday, December 09, 2011 06:59:29 PM Paul Brook wrote:
> ... and to be clear, the reason I don't care is because you're trying to
> solve a problem that doesn't interest me.
That's fine with me, the world would be a very boring place if we all shared
the same opinions and interests.
--
paul
> > > Last time I checked at least one of the Intel/AMD schemes had been
> > > implemented, through I don't know if it's been merged, or had any
> > > serious performance tuning. My main intent was to raise this as a
> > > potentially viable alternative. Someone who actually cares about the
> > >
On Friday, December 09, 2011 06:46:59 PM Paul Brook wrote:
> > > Last time I checked at least one of the Intel/AMD schemes had been
> > > implemented, through I don't know if it's been merged, or had any
> > > serious performance tuning. My main intent was to raise this as a
> > > potentially viab
> > Last time I checked at least one of the Intel/AMD schemes had been
> > implemented, through I don't know if it's been merged, or had any serious
> > performance tuning. My main intent was to raise this as a potentially
> > viable alternative. Someone who actually cares about the answer can
>
On Friday, December 09, 2011 05:32:19 PM Paul Brook wrote:
> > On Friday, December 09, 2011 04:17:50 PM Paul Brook wrote:
> > > > A group of us are starting to work on sandboxing QEMU device
> > > > emulation code. We're just getting started investigating
> > > > various approaches, and want to en
> On Friday, December 09, 2011 04:17:50 PM Paul Brook wrote:
> > > A group of us are starting to work on sandboxing QEMU device emulation
> > > code. We're just getting started investigating various approaches, and
> > > want to engage the community to gather input.
> > >
> > > Following are the
On Friday, December 09, 2011 04:17:50 PM Paul Brook wrote:
> > A group of us are starting to work on sandboxing QEMU device emulation
> > code. We're just getting started investigating various approaches, and
> > want to engage the community to gather input.
> >
> > Following are the design point
> A group of us are starting to work on sandboxing QEMU device emulation
> code. We're just getting started investigating various approaches, and
> want to engage the community to gather input.
>
> Following are the design points that we are currently considering:
>
> * Decompose QEMU into multi
On Wed, Dec 7, 2011 at 18:25, Corey Bryant wrote:
> A group of us are starting to work on sandboxing QEMU device emulation
> code. We're just getting started investigating various approaches, and
> want to engage the community to gather input.
>
> Following are the design points that we are curre
On 12/08/2011 04:47 AM, Stefan Hajnoczi wrote:
On Wed, Dec 7, 2011 at 7:32 PM, Corey Bryant wrote:
On 12/07/2011 01:48 PM, Anthony Liguori wrote:
On 12/07/2011 12:25 PM, Corey Bryant wrote:
* The trusted helper thread would run beside the untrusted thread,
enabling the untrusted thread t
On Wed, Dec 7, 2011 at 7:32 PM, Corey Bryant wrote:
>
>
> On 12/07/2011 01:48 PM, Anthony Liguori wrote:
>>
>> On 12/07/2011 12:25 PM, Corey Bryant wrote:
>>> * The trusted helper thread would run beside the untrusted thread,
>>> enabling the untrusted thread to make syscalls beyond read(),
>>> wr
On Wed, Dec 7, 2011 at 8:54 PM, Eric Paris wrote:
> On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote:
>> On 12/07/2011 01:32 PM, Corey Bryant wrote:
>
>> > That would seem like the logical approach. I think there may be new mode 2
>> > patches coming soon so we can see how they go over.
>>
On Wednesday, December 07, 2011 12:48:16 PM Anthony Liguori wrote:
> On 12/07/2011 12:25 PM, Corey Bryant wrote:
> > A group of us are starting to work on sandboxing QEMU device emulation
> > code. We're just getting started investigating various approaches, and
> > want to engage the community to
On Wed, 2011-12-07 at 13:43 -0600, Anthony Liguori wrote:
> On 12/07/2011 01:32 PM, Corey Bryant wrote:
> > That would seem like the logical approach. I think there may be new mode 2
> > patches coming soon so we can see how they go over.
>
> I'd like to see what the whitelist would need to be fo
On 12/07/2011 02:43 PM, Anthony Liguori wrote:
On 12/07/2011 01:32 PM, Corey Bryant wrote:
Agreed.
* The untrusted thread would be restricted by seccomp mode 1 and
would contain the device emulation code.
I think the best strategy would allow for a device to run either in the
untrusted th
On Wed, Dec 7, 2011 at 11:43 AM, Anthony Liguori wrote:
> I'd like to see what the whitelist would need to be for something like
> QEMU in mode 2. My biggest concern is that the whitelist would need to be
> so large that the practical security what's all that much improved.
>
Based on some proto
On 12/07/2011 01:32 PM, Corey Bryant wrote:
Agreed.
* The untrusted thread would be restricted by seccomp mode 1 and
would contain the device emulation code.
I think the best strategy would allow for a device to run either in the
untrusted thread or the trusted thread. This makes performance
On 12/07/2011 01:48 PM, Anthony Liguori wrote:
On 12/07/2011 12:25 PM, Corey Bryant wrote:
A group of us are starting to work on sandboxing QEMU device emulation
code. We're just getting started investigating various approaches, and
want to engage the community to gather input.
Following are
On 12/07/2011 12:25 PM, Corey Bryant wrote:
A group of us are starting to work on sandboxing QEMU device emulation
code. We're just getting started investigating various approaches, and
want to engage the community to gather input.
Following are the design points that we are currently considerin
A group of us are starting to work on sandboxing QEMU device emulation
code. We're just getting started investigating various approaches, and
want to engage the community to gather input.
Following are the design points that we are currently considering:
* Decompose QEMU into multiple processes
31 matches
Mail list logo
