linux-kernel - Re: [patch] inherited events not signalling parent on overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1506110025540.13723@vincent-weaver-1.umelst.maine.edu>
Date:	Thu, 11 Jun 2015 00:30:53 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Ingo Molnar <mingo@...nel.org>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	linux-kernel@...r.kernel.org, peterz@...radead.org,
	eranian@...gle.com, Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [patch] inherited events not signalling parent on overflow

On Fri, 29 May 2015, Ingo Molnar wrote:
 
> * Vince Weaver <vincent.weaver@...ne.edu> wrote:

> > If we inherit events, we inherit the signal state but not the fasync state, so 
> > overflows in inherited children will never trigger the signal handler.
> > 
> > Signed-off-by: Vince Weaver <vincent.weaver@...ne.edu>
> > 
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 1a3bf48..7df4cf5 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -8626,6 +8630,8 @@ inherit_event(struct perf_event *parent_event,
> >  	child_event->overflow_handler_context
> >  		= parent_event->overflow_handler_context;
> >  
> > +	child_event->fasync = parent_event->fasync;
> > +
> >  	/*
> >  	 * Precalculate sample_data sizes
> >  	 */

This patch, while it does work well enough to enable self-monitored-sampling 
of OpenMP programs, falls apart under fuzzing.

You end up with lots of

[25592.289382] kill_fasync: bad magic number in fasync_struct!

warnings and eventually I managed to lock up the system that way.

> Btw., if we do this (sensible looking) ABI fix, could we make it a new attr bit, 
> so that PAPI can essentially query the kernel whether this gets propagated 
> properly?
> 
> That way old kernels 'intentionally' don't inherit the fasync handler and tooling 
> can deterministically make use of this 'feature' on new kernels.

That would be useful.  PAPI typically has to guess about feature support 
(for workarounds) by using the kernel version number as a reference, and 
this falls apart on kernels such as RHEL which backport a lot of 
perf_event fixes/functionality.

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/