Re: [patch] perf_event_open.2 -- expand ERRORS section

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Hello Vince,

On 04/10/2014 10:30 PM, Vince Weaver wrote:
> On Thu, 10 Apr 2014, Michael Kerrisk (man-pages) wrote:
> 
>> I've applied this, but have a question or two below.
>>
>> On 04/07/2014 06:56 AM, Vince Weaver wrote:
> 
>>> +.B EACCES
>>> +Returned when the requested event requires root permissions
>>> +(or a more permissive perf_event paranoid setting).
>>> +Some common causes are attaching to a process owned by a different user,
>>> +monitoring all processes on a given cpu,
>>
>> I don't understand that line above. Could you clarify. How is
>> "monitoring all processes on a given given cpu" a cause of 
>> this error."
> 
> If you configure to monitor all processes by setting cpu=-1 then you
> are potentially measuring processes belonging to other users, which
> would be a security leak.  So you get EACCES.

I was just thrown a bit by your wording. I revised this a little to 
the following. Does it look okay?

       EACCES Returned when the requested event requires root  permis‐
              sions  (or  a  more  permissive perf_event paranoid set‐
              ting).  Some common cases where an unprivileged  process
              may  encounter  this  error:  are attaching to a process
              owned by a different user; monitoring all processes on a
              given CPU; and not setting exclude_kernel when the para‐
              noid setting requires it.

But, now I have some more questions:

* What are "root permissions" here? It's these days usual to express
  things precisely in terms of the required capability.
* I am puzzled by "monitoring all processes on a CPU"? So, monitoring 
  _some_ (i.e., < all) processes on a CPU won't trigger this error?

>>> +.B EPERM
>>> +Returned if sufficient permissions not available to create the event.

Again, somewhere here, the text should mention the required capability.

>>> +This includes attempting to set a breakpoint on a kernel address
>>> +and setting a ftrace function trace tracepoint.
>>
>> I don't understand the previous line. Why is "setting a ftrace function 
>> trace tracepoint" a cause of EPERM?
> 
> Would it be cleared if it were "ftrace function-trace tracepoint"?

That would help.

> This is a recent change.  

So, the text should mention a kernel version number. Could you patch 
that please. I guess it should be something like:

    and (since Linux 3.??) setting an ftrace function-trace tracepoint

> It was a lockup bug we found, it turns out
> that letting an average user set function-trace tracepoints can cause
> problems, if for example they set a tracepoint in an interrupt handler
> that causes an overflow that triggers an interrupt you get a recursive 
> loop.  The easy solution was to just make function-trace tracepoints
> root-only (meaning that yes, root can crash the kernel easily using 
> perf_event_open() ).
> 
> Now why it returns EPERM not EACCES, I don't know.
> 
> I can try to update the text in these two cases to be a bit more clear.
> I'm never sure how much extra details like this are suitable without
> overwhelming the document with extraneous details.

If you could send some patch(es) to fix the above, that would be good.
As ever, thanks for your great work on this page.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html