Unify KVM kernel-space and user-space code into a single project
in [Kernel]
|
Prev: Irish 2010 Grant Winner
Next: [PATCH] staging: winbond: mds_f.h whitespace and CamelCase corrections.
From: Avi Kivity on 24 Mar 2010 12:40 On 03/24/2010 06:31 PM, Joerg Roedel wrote: > 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 ;-) > That's just what I want to do. Leave it in userspace and then they can deal with it without telling us about it. -- error compiling committee.c: too many arguments to function -- 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: Avi Kivity on 24 Mar 2010 12:50 On 03/24/2010 06:45 PM, Joerg Roedel wrote: > >> That's just what I want to do. Leave it in userspace and then they can >> deal with it without telling us about it. >> > They can't do that with a directory in /proc? > > I don't know. -- error compiling committee.c: too many arguments to function -- 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: Peter Zijlstra on 24 Mar 2010 12:50 On Wed, 2010-03-24 at 17:23 +0100, Joerg Roedel wrote: > 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? No, what if it maps new things after you read it? But still getting the pid of the guest process seems non trivial without guest kernel support. -- 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: Avi Kivity on 24 Mar 2010 13:00 On 03/24/2010 06:47 PM, Avi Kivity wrote: > > It's true. If the kernel provides something, there are fewer things > that can break. But if your system is so broken that you can't > resolve uids, fix that before running perf. Must we design perf for > that case? > > After all, 'ls -l' will break under the same circumstances. It's hard > to imagine doing useful work when that doesn't work. Also, perf itself will hang if it needs to access a file using autofs or nfs, and those are broken. -- error compiling committee.c: too many arguments to function -- 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: Avi Kivity on 24 Mar 2010 14:30
On 03/24/2010 07:47 PM, Arnaldo Carvalho de Melo wrote: > Em Wed, Mar 24, 2010 at 06:09:30PM +0200, Avi Kivity escreveu: > >> Doesn't perf already has a dependency on naming conventions for finding >> debug information? >> > It looks at several places, from most symbol rich (/usr/lib/debug/, aka > -debuginfo packages, where we have full symtabs) to poorest (the > packaged binary, where we may just have a .dynsym). > > In an ideal world, it would just get the build-id (a SHA1 cookie that is > in an ELF session inserted in every binary (aka DSOs), kernel module, > kallsyms or vmlinux file) and use that to look first in a local cache > (implemented in perf for a long time already) or in some symbol server. > > For instance, for a random perf.data file I collected here in my machine > I have: > > [acme(a)doppio linux-2.6-tip]$ perf buildid-list | grep libpthread > 5c68f7afeb33309c78037e374b0deee84dd441f6 /lib64/libpthread-2.10.2.so > [acme(a)doppio linux-2.6-tip]$ > > So I don't have to access /lib64/libpthread-2.10.2.so directly, nor some > convention to get a debuginfo in a local file like: > > /usr/lib/debug/lib64/libpthread-2.10.2.so.debug > > Instead the tools look at: > > [acme(a)doppio linux-2.6-tip]$ l ~/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 > lrwxrwxrwx 1 acme acme 73 2010-01-06 18:53 /home/acme/.debug/.build-id/5c/68f7afeb33309c78037e374b0deee84dd441f6 -> ../../lib64/libpthread-2.10.2.so/5c68f7afeb33309c78037e374b0deee84dd441f6* > > To find the file for that specific build-id, not the one installed in my > machine (or on the different machine, of a different architecture) that > may be completely unrelated, a new one, or one for a different arch. > Thanks. I believe qemu could easily act as a symbol server for this use case. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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/ |