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...