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

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] [day] [month] [year] [list]

Message-ID: <Y39InxmwK88yKkyp@hirez.programming.kicks-ass.net>
Date:   Thu, 24 Nov 2022 11:34:07 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Marco Elver <elver@...gle.com>
Cc:     Pengfei Xu <pengfei.xu@...el.com>, peter.zijlstra@...el.com,
        linux-kernel@...r.kernel.org, heng.su@...el.com,
        Mark Rutland <mark.rutland@....com>
Subject: Re: [Syzkaller & bisect] There is "__perf_event_overflow" WARNING in
 v6.1-rc5 kernel in guest

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@...radead.org> wrote:
> 
> > > Subject: perf: Consider OS filter fail
> > > From: Peter Zijlstra <peterz@...radead.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@...el.com>
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > > Tested-by: Pengfei Xu <pengfei.xu@...el.com>
> > > Link: https://lkml.kernel.org/r/Y3hDYiXwRnJr8RYG@xpf.sh.intel.com
> > 
> > Thanks, FWIW
> > 
> > Reviewed-by: Marco Elver <elver@...gle.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.