Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: [PATCH 1/5] x86-32: Split cache flush handler from simd handler
Next: [RESEND][PATCH 1/3] Add tracing_off_event() to stop tracing when a bug or warning occur
From: Joerg Roedel on 24 Mar 2010 12:00 On Wed, Mar 24, 2010 at 05:43:31PM +0200, Avi Kivity wrote: > On 03/24/2010 05:37 PM, Joerg Roedel wrote: >> Even better. So a guest which breaks out can't even access its own >> /sys/kvm/ directory. Perfect, it doesn't need that access anyway. > > But what security label does that directory have? How can we make sure > that whoever needs access to those files, gets them? > > Automatically created objects don't work well with that model. They're > simply missing information. If we go the /proc/<pid>/kvm way then the directory should probably inherit the label from /proc/<pid>/? Same could be applied to /sys/kvm/guest/ if we decide for it. The VM is still bound to a single process with a /proc/<pid> after all. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 24 Mar 2010 12:00 On Wed, Mar 24, 2010 at 05:49:42PM +0200, Avi Kivity wrote: > On 03/24/2010 05:46 PM, Joerg Roedel wrote: >> On Wed, Mar 24, 2010 at 05:12:55PM +0200, Avi Kivity wrote: >> >>> On 03/24/2010 05:01 PM, Joerg Roedel wrote: >>> >>>> $ cd /sys/kvm/guest0 >>>> $ ls -l >>>> -r-------- 1 root root 0 2009-08-17 12:05 name >>>> dr-x------ 1 root root 0 2009-08-17 12:05 fs >>>> $ cat name >>>> guest0 >>>> $ # ... >>>> >>>> The fs/ directory is used as the mount point for the guest root fs. >>>> >>> The problem is /sys/kvm, not /sys/kvm/fs. >>> >> I am not tied to /sys/kvm. We could also use /proc/<pid>/kvm/ for >> example. This would keep anything in the process space (except for the >> global list of VMs which we should have anyway). >> > > How about ~/.qemu/guests/$pid? That makes it hard for perf to find it and even harder to get a list of all VMs. With /proc/<pid>/kvm/guest we could symlink all guest directories to /proc/kvm/ and perf reads the list from there. Also perf can easily derive the directory for a guest from its pid. Last but not least its kernel-created and thus independent from the userspace part being used. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 24 Mar 2010 12:20 On Wed, Mar 24, 2010 at 05:52:54PM +0200, Avi Kivity wrote: > On 03/24/2010 05:50 PM, Joerg Roedel wrote: >> If we go the /proc/<pid>/kvm way then the directory should probably >> inherit the label from /proc/<pid>/? > > That's a security policy. The security people like their policies > outside the kernel. > > For example, they may want a label that allows a trace context to read > the data, and also qemu itself for introspection. Hm, I am not a security expert. But is this not only one entity more for sVirt to handle? I would leave that decision to the sVirt developers. Does attaching the same label as for the VM resources mean that root could not access it anymore? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 24 Mar 2010 12:30 On Wed, Mar 24, 2010 at 05:03:42PM +0100, Peter Zijlstra wrote: > On Wed, 2010-03-24 at 16:01 +0100, Joerg Roedel wrote: > > > What I meant was: perf-kernel puts the guest-name into every sample and > > perf-userspace accesses /sys/kvm/guest_name/fs/ later to resolve the > > symbols. I leave the question of how the guest-fs is exposed to the host > > out of this discussion. We should discuss this seperatly. > > I'd much prefer a pid like suggested later, keeps the samples smaller. > > But that said, we need guest kernel events like mmap and context > switches too, otherwise we simply can't make sense of guest userspace > addresses, we need to know the guest address space layout. With the filesystem approach all we need is the pid of the guest process. Then we can access proc/<pid>/maps of the guest and read out the address space layout, no? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 24 Mar 2010 12:40
On Wed, Mar 24, 2010 at 06:20:38PM +0200, Avi Kivity wrote: > On 03/24/2010 06:17 PM, Joerg Roedel wrote: >> But is this not only one entity more for >> sVirt to handle? I would leave that decision to the sVirt developers. >> Does attaching the same label as for the VM resources mean that root >> could not access it anymore? >> > > IIUC processes run under a context, and there's a policy somewhere that > tells you which context can access which label (and with what > permissions). There was a server on the Internet once that gave you > root access and invited you to attack it. No idea if anyone succeeded > or not (I got bored after about a minute). > > So it depends on the policy. If you attach the same label, that means > all files with the same label have the same access permissions. I think. So if this is true we can introduce a 'trace' label and add all contexts that should be allowed to trace to it. But we probably should leave the details to the security experts ;-) Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |