Avi Kivity wrote: > The trick I mentioned (copying a pgd entry) means: > > - guest physical and host userspace are different (have different pgds) > - guest physical (offset 0) is aliased to host userspace (offset $bignum) > - guest address space is limited to 2^(12+9*3) > - the pte dirty and accessed bits are shared > > so guest userspace is not exposed, but the guest ptes _are_ shared. > > In a way, this is similar to shared memory, if shared page tables are > ever implemented. Think of a shared memory segment mapped at two > different offsets, but aligned at a pud boundary so everything below the > pgd entry is sharable. Nasty. We could also mask out host userspace while having guest memory mapped to it: our hw control block allows to set an offset and a memory size for the virtual image. This way, we can allow the virtual machine to work on a subset of the host user address space. At this time, our userspace does not use that feature because we had a different security model in mind (below).
>> Our implementation does use action bits preseted to sys_s390host_sie >> to update the hardware control blocks for the virutal machine. The >> hardware control blocks would be mapped read-only to user address >> space. This way, the kernel can enforce the user not to mess things >> up, which allows to run non-privileged user code (userid johndoe >> instead of root). Would this approach be reasonable on x86 too? > > Allowing the guest to hack the host userspace exposes the rest of the > user's processes to a malicious guest, and allows the guest to open > network connections through the host, no? The security model we had in mind was, that the user who starts the userspace program equals root on the guest system but does not equal root on the host. This way, we have seperate users by means of regular kernel security barriers in the host linux: the user johndoe is capable of messing with his personal virtual machines and other resources, but can not mess with virtual machines and other resources belonging to other users. If the guest root choses to be malicious, he might well be able to take over the userspace and mess up with whatever the user is allowed to do on the host. Frankly this does not mean we want to leave the door open for the guest intentionally, just that it is not an integral security issue for the hosting Linux if we would have a security bug. Looks to me, like we have different security models today. If our model to start guests as regular user would work on all platforms without causing performance penalty, I think it would be worth to do that extra effort. If not, we could also implement the current kvm security barrier and reduce complexity of our s390host code. so long, Carsten ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
