Re: [PATCH 2/2] perf: Userspace software event and ioctl

On Thu, 2014-09-25 at 19:33 +0100, Ingo Molnar wrote:

quoted

How would we select tasks that can write to a given buffer? Maybe an
ioctl() on a perf fd? Something like this?

	ioctl(perf_fd, PERF_EVENT_IOC_ENABLE_UEVENT, pid);
	ioctl(perf_fd, PERF_EVENT_IOC_DISABLE_UEVENT, pid);

No, I think there's a simpler way: this should be a regular 
perf_attr flag, which defaults to '0' (tasks cannot do this), but 
which can be set to 1 if the profiler explicitly allows such 
event injection.

As in: allows *all* tasks to inject the data? Are you sure we don't want
more fine-grained control, in particular per task?

If we have two buffers, both created with the "injecting allowed" flag,
do we inject a given uevent into both of them?

I.e. whether user-events are allowed is controlled by the 
profiling/tracing context, via the regular perf syscall. It would 
propagate into the perf context, so it would be easy to check at 
event generation time.

It would definitely be the profiling/tracing tools that would decide if
the injection is allowed, no question about that. I just feel that it
should be able to select the tasks that can do that, not just flip a big
switch saying "everyone is welcome". Other question is: should a
non-root context be able to receive events from root processes? Wouldn't
it be a security hole (for example, it could be used as a kind of covert
channel)? Maybe we should do what ptrace does? As in: if a task can
ptrace another task, it can also receive uevents from it.

Pawel