lkml.org 
[lkml]   [2009]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2009-08-19 18:07    [W:0.131 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site