on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh?
The idea was discussed briefly couple of months ago, but never got off
the ground - which is a shame IMO.
It's easy to explain the problem: If an attacker finds
On 11/06/2011 10:40 PM, Sasha Levin wrote:
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh?
Actually, no.
The idea was discussed briefly couple of months ago, but never got off
the ground
really the case, then mapping guest memory is preferable.
While mmap() is an issue, I think it's a great example of why seccomp
filters are needed in the kernel, and might be a good chance to push
that feature forward. In that sense, 'Secure KVM' could be used as a
guinea pig both for seccomp filters
forward. In that sense, 'Secure KVM' could be used as a
guinea pig both for seccomp filters and future QEMU work.
Sure.
Another direction we're looking up is making it harder to exploit a
vulnerability. PIC/PIE (position independent code/executable) make it
harder to exploit a bug; and selinux
forward. In that sense, 'Secure KVM' could be used as a
guinea pig both for seccomp filters and future QEMU work.
This is a really interesting topic - something that we've discussed in
QEMU as well.
Doing it with seccomp is really hard since that only allows read(2),
write(2), exit(2
are needed in the kernel, and might be a good chance to push
that feature forward. In that sense, 'Secure KVM' could be used as a
guinea pig both for seccomp filters and future QEMU work.
This is a really interesting topic - something that we've discussed in
QEMU as well.
Doing it with seccomp
On 11/07/2011 02:40 PM, Sasha Levin wrote:
Where does the VNC server, the image formats, etc go? It would be
nice to confine them too.
Regarding image formats, just wondering - was there ever any plan to
merge (at least some of them) into the kernel?
Xen has/had something where (IIUC)
On Mon, Nov 7, 2011 at 12:51 PM, Avi Kivity a...@redhat.com wrote:
On 11/07/2011 02:40 PM, Sasha Levin wrote:
Where does the VNC server, the image formats, etc go? It would be
nice to confine them too.
Regarding image formats, just wondering - was there ever any plan to
merge (at least
On 11/06/2011 02:40 PM, Sasha Levin wrote:
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh?
The idea was discussed briefly couple of months ago, but never got off
the ground - which is a shame IMO
On 11/07/2011 03:26 AM, Avi Kivity wrote:
On 11/06/2011 10:40 PM, Sasha Levin wrote:
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh?
Actually, no.
The idea was discussed briefly couple
On 11/07/2011 05:27 AM, Stefan Hajnoczi wrote:
On Mon, Nov 7, 2011 at 10:17 AM, Sasha Levinlevinsasha...@gmail.com wrote:
This is a really interesting topic - something that we've discussed in
QEMU as well.
Doing it with seccomp is really hard since that only allows read(2),
write(2),
Hi Anthony,
Thank you for your comments!
On Mon, 2011-11-07 at 11:37 -0600, Anthony Liguori wrote:
On 11/06/2011 02:40 PM, Sasha Levin wrote:
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh
On 11/07/2011 11:52 AM, Sasha Levin wrote:
Hi Anthony,
Thank you for your comments!
On Mon, 2011-11-07 at 11:37 -0600, Anthony Liguori wrote:
On 11/06/2011 02:40 PM, Sasha Levin wrote:
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled
On 11/07/2011 07:43 PM, Anthony Liguori wrote:
In that respect I think Avi's ideas about using safe programming
languages (even if just a NaCl toolchain) are nice because they are
more general and apply to all of the codebase.
It's a nice idea but the NaCL toolchain doesn't have a nice
On 11/07/2011 07:39 PM, Anthony Liguori wrote:
One thing to beware of is memory hotplug. If the memory map is static,
then a fork() once everything is set up (with MAP_SHARED) alllows all
processes to access guest memory. However, if memory hotplug is
supported (or planned to be supported),
On 11/07/2011 12:43 PM, Avi Kivity wrote:
On 11/07/2011 07:39 PM, Anthony Liguori wrote:
One thing to beware of is memory hotplug. If the memory map is static,
then a fork() once everything is set up (with MAP_SHARED) alllows all
processes to access guest memory. However, if memory hotplug is
On 11/07/2011 09:07 PM, Anthony Liguori wrote:
We lost the context of all threads, but that also happens on live
migration. I'm sure this is workable.
Plus we get save/restore testing for free. Did someone say win/win?
Indeed.
But it mandates that everything in the sandbox be
On Mon, 07 Nov 2011 12:03:38 -0600, Anthony Liguori anth...@codemonkey.ws
wrote:
So the sandbox loop would look like:
void main() {
setup_devices();
read_from_event_channel(main_channel);
for i in vrings:
check_vring_notification(i);
}
lguest uses a model where you
On Mon, 07 Nov 2011 08:29:03 +0200, Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-11-07 at 10:37 +1030, Rusty Russell wrote:
On Sun, 06 Nov 2011 22:40:20 +0200, Sasha Levin levinsasha...@gmail.com
wrote:
The solution is also simple to explain: Split the devices into different
On Mon, 07 Nov 2011 11:26:53 +0200, Avi Kivity a...@redhat.com wrote:
One thing to beware of is memory hotplug. If the memory map is static,
then a fork() once everything is set up (with MAP_SHARED) alllows all
processes to access guest memory. However, if memory hotplug is
supported (or
Hi all,
I'm planning on doing a small fork of the KVM tool to turn it into a
'Secure KVM' enabled hypervisor. Now you probably ask yourself, Huh?
The idea was discussed briefly couple of months ago, but never got off
the ground - which is a shame IMO.
It's easy to explain the problem
On Sun, 06 Nov 2011 22:40:20 +0200, Sasha Levin levinsasha...@gmail.com wrote:
The solution is also simple to explain: Split the devices into different
processes and use seccomp to sandbox each device into the exact set of
resources it needs to operate, nothing more and nothing less.
lguest
On Mon, 2011-11-07 at 10:37 +1030, Rusty Russell wrote:
On Sun, 06 Nov 2011 22:40:20 +0200, Sasha Levin levinsasha...@gmail.com
wrote:
The solution is also simple to explain: Split the devices into different
processes and use seccomp to sandbox each device into the exact set of
resources
On Mon, Nov 7, 2011 at 8:29 AM, Sasha Levin levinsasha...@gmail.com wrote:
As you said, clone() isn't really an option - sharing things like the VM
and handles is something which I want to avoid. How does your patch
handle IPC?
Use the unshare() system call?
--
To unsubscribe from this list:
On Mon, 2011-11-07 at 08:37 +0200, Pekka Enberg wrote:
On Mon, Nov 7, 2011 at 8:29 AM, Sasha Levin levinsasha...@gmail.com wrote:
As you said, clone() isn't really an option - sharing things like the VM
and handles is something which I want to avoid. How does your patch
handle IPC?
Use
On Mon, 7 Nov 2011, Sasha Levin wrote:
Yup, but you must somehow communicate with the master process, and this
is currently missing from the lguest implementation since everything is
shared (vm + fds).
If you simply unshare it, you must have a different method of talking
with the master
26 matches
Mail list logo
