Hi Avi, Thank you for your comments! Just one question below: On Mon, Nov 7, 2011 at 11:26 AM, Avi Kivity <avi@xxxxxxxxxx> wrote: > Crashing the guest is fine (not 100% - you can have unprivileged code > managing a device, in which case we allow unprivileged code to crash the > entire guest - but that's rare). Running code on the host is also fine; On Mon, Nov 7, 2011 at 11:26 AM, Avi Kivity <avi@xxxxxxxxxx> 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), then you can't do that, as > seccomp doesn't allow you to run mmap() in confined processes. > > This means they have to use RPC to the main process in order to access > memory, which is going to slow them down significantly. Is the risk of a non-privileged guest code being able to exploit hypervisor to access guest memory which it's not allowed to access is really that small? I actually thought it would be one of the main concerns we'd need to handle, but from what I understand from you it's an irrelevant scenario. If it's 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 and future QEMU work. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
