Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest

From: Peter Zijlstra <peterz@infradead.org>
To: Marco Elver <elver@google.com>
Cc: Pengfei Xu <pengfei.xu@intel.com>,
	peter.zijlstra@intel.com, linux-kernel@vger.kernel.org,
	heng.su@intel.com, Mark Rutland <mark.rutland@arm.com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in v6.1-rc5 kernel in guest
Date: Thu, 24 Nov 2022 11:34:07 +0100	[thread overview]
Message-ID: <Y39InxmwK88yKkyp@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <Y38ylOkbhoBEYZjD@hirez.programming.kicks-ass.net>

On Thu, Nov 24, 2022 at 10:00:04AM +0100, Peter Zijlstra wrote:
> On Thu, Nov 24, 2022 at 09:31:10AM +0100, Marco Elver wrote:
> > On Wed, 23 Nov 2022 at 16:05, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > > Subject: perf: Consider OS filter fail
> > > From: Peter Zijlstra <peterz@infradead.org>
> > > Date: Sat, 19 Nov 2022 10:45:54 +0800
> > >
> > > Some PMUs (notably the traditional hardware kind) have boundary issues
> > > with the OS filter. Specifically, it is possible for
> > > perf_event_attr::exclude_kernel=1 events to trigger in-kernel due to
> > > SKID or errata.
> > >
> > > This can upset the sigtrap logic some and trigger the WARN.
> > >
> > > However, if this invalid sample is the first we must not loose the
> > > SIGTRAP, OTOH if it is the second, it must not override the
> > > pending_addr with an invalid one.
> > >
> > > Fixes: ca6c21327c6a ("perf: Fix missing SIGTRAPs")
> > > Reported-by: Pengfei Xu <pengfei.xu@intel.com>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > > Tested-by: Pengfei Xu <pengfei.xu@intel.com>
> > > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com
> > 
> > Thanks, FWIW
> > 
> > Reviewed-by: Marco Elver <elver@google.com>
> > 
> > One thing I wondered was, if the event fired in the kernel due to
> > skid, is the addr always some kernel address, or does this also depend
> > on the type of PMU? In any case, we don't even want to risk leaking
> > kernel addresses this way, so this looks sane.
> 
> That very much depends on the PMU and event. Most events will not fill
> out ->addr at all, some memop specific events can, but only when
> combined with PERF_SAMPLE_ADDR.
> 
> Typically it will then retain the address of the memop. On Intel it's
> mostly just PEBS events that can provide the ADDR and they'll have less
> such trouble. On AMD we have IBS that can do ADDR but I've forgotten
> much about IBS. PowerPC64 also can do ADDR and there I've no clue.

This is also not taking CPU Errata into consideration; there's plenty of
them where the OS filter is 'delayed', in which case you get actual
kernel samples in your 'user only' stream.