From: William C. <wc...@nc...> - 2002-03-27 15:51:02
Attachments:
20020327.user.oprofile.patch
|
It would be really nice to reduce the need for root access when using oprofile. I have made some modifications in my local version of oprofile to make the /proc/sys/dev/oprofile readable by users other than root. This allows a user run op_help to determine what processor is being used and what types of instrumentation it supports. /proc/sys/dev/oprofile/dump is world writable to allow normal users to initiate a flush of the profiling data (like a sync command), so they don't have to wait for a periodic flush of profiling data to occur. Change log entries: * module/oprofile.c (oprof_table): Allow non-root examination of /proc/sys/dev/oprofile and non-root initiation of dump. * dae/op_dump: Allow normal user profiling data dump. Does this seems reasonable? How does oprofile handle a changes in an executable? Does oprofile determine executable has changed and the old collected data is deleted and a new profiling data file is started? I am thinking of the case where a developer changes something in the source code, recompiles, and then wants data only related to the new executable (which has the same name as the old executable). -Will |
From: John L. <le...@mo...> - 2002-03-27 16:11:25
|
On Wed, Mar 27, 2002 at 09:15:54AM -0500, William Cohen wrote: > It would be really nice to reduce the need for root access when using > oprofile. Yes, this has been on TODO for a while ... > I have made some modifications in my local version of oprofile > to make the /proc/sys/dev/oprofile readable by users other than root. > This allows a user run op_help to determine what processor is being used > and what types of instrumentation it supports. Looks good, I will review and test it properly later. > /proc/sys/dev/oprofile/dump is world writable to allow normal users to > initiate a flush of the profiling data (like a sync command), so they > don't have to wait for a periodic flush of profiling data to occur. The question is, can a local user cause a mini-DOS by spamming dump ? And is it a problem ? > How does oprofile handle a changes in an executable? Does oprofile > determine executable has changed and the old collected data is deleted > and a new profiling data file is started? I am thinking of the case > where a developer changes something in the source code, recompiles, and > then wants data only related to the new executable (which has the same > name as the old executable). The image's mtime is checked every time it is mapped in and the old sample file is deleted. In the future it will be made simpler for the user to compare the profiles of two different compilations (though they will still probably have to save the old image file themselves) regards john p.s. I much prefer diff -u format -- "Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy." - John Hasler <jo...@dh...> |
From: William C. <wc...@nc...> - 2002-03-27 22:38:31
|
John Levon wrote: > On Wed, Mar 27, 2002 at 09:15:54AM -0500, William Cohen wrote: > > >>It would be really nice to reduce the need for root access when using >>oprofile. >> > > Yes, this has been on TODO for a while ... > > >>I have made some modifications in my local version of oprofile >> to make the /proc/sys/dev/oprofile readable by users other than root. >>This allows a user run op_help to determine what processor is being used >>and what types of instrumentation it supports. >> > > Looks good, I will review and test it properly later. > > >>/proc/sys/dev/oprofile/dump is world writable to allow normal users to >>initiate a flush of the profiling data (like a sync command), so they >>don't have to wait for a periodic flush of profiling data to occur. >> > > The question is, can a local user cause a mini-DOS by spamming dump ? > > And is it a problem ? I much prefer the possibility of someone slowing down the machine with repeated 'op_dump' than to require giving root access to anyone doing performance monitoring. Doesn't 'sync' have similar issues? I will play around with the multiple op_dump and see whether it is a problem. >>How does oprofile handle a changes in an executable? Does oprofile >>determine executable has changed and the old collected data is deleted >>and a new profiling data file is started? I am thinking of the case >>where a developer changes something in the source code, recompiles, and >>then wants data only related to the new executable (which has the same >>name as the old executable). >> > > The image's mtime is checked every time it is mapped in and the old > sample file is deleted. Great. I haven't looked at that aspect of the oprofile yet. That is one thing I wasn't sure of. This behavior will life easier for developers > In the future it will be made simpler for the user to compare the > profiles of two different compilations (though they will still probably > have to save the old image file themselves) For many cases it would be pretty simple for the programmer to copy the file to a unique place and then run the file. However, for program that do exec or for system wide profiling this might be more of a problem. > regards > john > > p.s. I much prefer diff -u format Okay, will use "diff -u" in the future. -Will |
From: John L. <le...@mo...> - 2002-03-27 23:27:08
|
On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > I much prefer the possibility of someone slowing down the machine with > repeated 'op_dump' than to require giving root access to anyone doing Actually an admin can currently add oprof_start to sudo list safely (as far as I know). We need to be careful not to make security promises we can't live up to, and I am not really an expert in this arena... It would be relatively easy to make a command line version of oprof_start that could be sudo'd too - obviously, op_start is too easily exploitable to serve for this. Allowing a normal user to dump isn't particularly useful if they can't control counter parameters etc. and that requires what I mention above. Having said that, I'm not necessarily averse to it, we just need to be sure of what we are doing. In particular: are we sure that all the minimum values for every event type is totally DoS-free even on the latest processors ?? Partly this is a documentation issue of course. > For many cases it would be pretty simple for the programmer to copy the > file to a unique place and then run the file. However, for program that > do exec or for system wide profiling this might be more of a problem. Well it's reasonable to expect that a user can keep track of the old executables when they change something, and they need a comparison more detailed than op_time's. regards john -- "Q: Name a non-living object with legs A: A plant." - Family Fortunes |
From: William C. <wc...@nc...> - 2002-03-28 14:52:18
|
John Levon wrote: > On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > > >>I much prefer the possibility of someone slowing down the machine with >>repeated 'op_dump' than to require giving root access to anyone doing >> > > Actually an admin can currently add oprof_start to sudo list safely (as > far as I know). We need to be careful not to make security promises we > can't live up to, and I am not really an expert in this arena... > > It would be relatively easy to make a command line version of > oprof_start that could be sudo'd too - obviously, op_start is too easily > exploitable to serve for this. > > Allowing a normal user to dump isn't particularly useful if they can't > control counter parameters etc. and that requires what I mention above. > > Having said that, I'm not necessarily averse to it, we just need to be > sure of what we are doing. In particular: are we sure that all the > minimum values for every event type is totally DoS-free even on the > latest processors ?? > > Partly this is a documentation issue of course. To some extent having op_dump as runnable by a normal user is a stop-gap measure. It just allows the user to get some profiling information even if they do not have root. However, the user is at the mercy of root to set the profiling to things the user is interested in. Hopefully, root will set the performance monitoring to something of general utility. Because the profiling hardware is a scarse resource there are going to be issues with allocating the performance monitoring resources. More than one user may want to collect data using the performance monitoring registers. There is needs to be some locking to make sure that one user's data collection is not terminated by another user changing the performance monitoring settings. Oprofile will start a new set of samples any time a change is made in the profiling configuration. There are some things like where the sample data is stored which would have to be limited and things like what kernel is being profile would be off limits to normal user changes. I don't know how feasible it would be to have the performance monitoring register allocated individually to allow more than one user to use the hardware at the same time. There would be complications. How to handle changes in performance monitoring setting. Some files would be affected others would not. There wouldn't be the nice property that everything in the directory is from the same sampling epoc. -Will |
From: Keith W. <ke...@tu...> - 2002-03-28 15:06:02
|
William Cohen wrote: > > John Levon wrote: > > > On Wed, Mar 27, 2002 at 11:43:29AM -0500, William Cohen wrote: > > > > > >>I much prefer the possibility of someone slowing down the machine with > >>repeated 'op_dump' than to require giving root access to anyone doing > >> > > > > Actually an admin can currently add oprof_start to sudo list safely (as > > far as I know). We need to be careful not to make security promises we > > can't live up to, and I am not really an expert in this arena... > > > > It would be relatively easy to make a command line version of > > oprof_start that could be sudo'd too - obviously, op_start is too easily > > exploitable to serve for this. > > > > Allowing a normal user to dump isn't particularly useful if they can't > > control counter parameters etc. and that requires what I mention above. > > > > > Having said that, I'm not necessarily averse to it, we just need to be > > sure of what we are doing. In particular: are we sure that all the > > minimum values for every event type is totally DoS-free even on the > > latest processors ?? > > > > Partly this is a documentation issue of course. > > To some extent having op_dump as runnable by a normal user is a stop-gap > measure. It just allows the user to get some profiling information even > if they do not have root. However, the user is at the mercy of root to > set the profiling to things the user is interested in. Hopefully, root > will set the performance monitoring to something of general utility. Seeing as you have a kernel module already, why not add some ioctls there to do the things that currently require root access? Have the kernel module verify that the requests are sane & secure. > Because the profiling hardware is a scarse resource there are going to > be issues with allocating the performance monitoring resources. More > than one user may want to collect data using the performance monitoring > registers. There is needs to be some locking to make sure that one > user's data collection is not terminated by another user changing the > performance monitoring settings. Oprofile will start a new set of > samples any time a change is made in the profiling configuration. There > are some things like where the sample data is stored which would have to > be limited and things like what kernel is being profile would be off > limits to normal user changes. You could just return a busy error, rather than trying to virtualize the hardware. I'm not sure how you'd do that, and I'm not sure how many people would require that... Keith |
From: John L. <le...@mo...> - 2002-03-28 15:32:19
|
On Thu, Mar 28, 2002 at 03:04:00PM +0000, Keith Whitwell wrote: > Seeing as you have a kernel module already, why not add some ioctls there to > do the things that currently require root access? Have the kernel module > verify that the requests are sane & secure. This already happens in fact. See pmc_check_params(). > You could just return a busy error, rather than trying to virtualize the > hardware. I'm not sure how you'd do that, and I'm not sure how many people > would require that... I don't think there's a simple way to prevent one user messing with another user's profile setup (given that they would both have the necessary privileges), but this question is orthogonal to the use of root in oprofile code - this problem exists either way. I'd quite happily have the minimum of code running as root, but we would need to make sure that the admin can still restrict the privilege of messing with profile stuff to users who they allow. Currently this is done via sudo / giving them root. regards john -- "To the untrained eye it might seem as though Quality programs and ISO 9000 are not related. I was confused too until one consultant explained it to me this way : 'ISO 9000 is closely related to Quality because everything you do is Quality and ISO 9000 documents everything you do, therefore give us money.'" - Scott Adams |
From: John L. <le...@mo...> - 2002-04-30 19:26:41
|
On Wed, Mar 27, 2002 at 09:15:54AM -0500, William Cohen wrote: > It would be really nice to reduce the need for root access when using > oprofile. I have made some modifications in my local version of oprofile > to make the /proc/sys/dev/oprofile readable by users other than root. I have applied your patch. I have also extended it so that the user can read the 0/ and 1/ directories. Sorry about the long delay regards john -- "Please let's not resume the argument with the usual whining about how this feature will wipe out humanity or bring us to the promised land." - Charles Campbell on magic words in Subject: headers |