Messages in this thread | | | Date | Wed, 19 Aug 2009 18:04:39 +0200 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 1/4] perf_counter: Default to higher paranoia level |
| |
On Wed, Aug 19, 2009 at 04:07:33PM +0200, Peter Zijlstra wrote: > On Wed, 2009-08-19 at 11:18 +0200, Peter Zijlstra wrote: > > > +static inline bool perf_paranoid_anon(void) > > +{ > > + return !capable(CAP_SYS_ADMIN) && sysctl_perf_counter_paranoid > 1; > > } > > > > static inline bool perf_paranoid_kernel(void) > > { > > - return sysctl_perf_counter_paranoid > 1; > > + return !capable(CAP_SYS_ADMIN) && sysctl_perf_counter_paranoid > 2; > > +} > > OK, this is buggy: > > - capable() uses current, which is unlikely to be counter->owner, > - but even security_real_capable(counter->owner, ...) wouldn't > work, since the ->capable() callback isn't NMI safe > (selinux takes locks and does allocations in that path). > > This puts a severe strain on more complex anonymizers since its > basically impossible to tell if counter->owner has permissions on > current from NMI context. > > I'll fix up this patch to pre-compute the perf_paranoid_anon_ip() per > counter based on creation time state, unless somebody has a better idea.
Something I don't understand there: it's about wide per cpu profiling, then the task that have been created before the counter can also be profiled, then how is the creation time useful here?
> I could possibly only anonymize IRQ context (SoftIRQ context is > difficult since in_softirq() means both in-softirq and > softirq-disabled).
I don't understand why we need to set this paranoid level concerning kernel RIPS.
| |