[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240710162311.gz3njyjshraeuto7@treble>
Date: Wed, 10 Jul 2024 09:24:51 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andrii Nakryiko <andrii@...nel.org>,
linux-trace-kernel@...r.kernel.org, rostedt@...dmis.org,
mhiramat@...nel.org, x86@...nel.org, mingo@...hat.com,
tglx@...utronix.de, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, rihams@...com,
linux-perf-users@...r.kernel.org, rick.p.edgecombe@...el.com
Subject: Re: [PATCH v4] perf,x86: avoid missing caller address in stack
traces captured in uprobe
On Wed, Jul 10, 2024 at 08:11:57AM -0700, Andrii Nakryiko wrote:
> On Wed, Jul 10, 2024 at 4:39 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > On Tue, Jul 09, 2024 at 10:50:00AM -0700, Andrii Nakryiko wrote:
> > > You can see it replaced the first byte, the following 3 bytes are
> > > remnants of endb64 (gdb says it's a nop? :)), and then we proceeded,
> > > you can see I stepped through a few more instructions.
> > >
> > > Works by accident?
> >
> > Yeah, we don't actually have Userspace IBT enabled yet, even on hardware
> > that supports it.
>
> OK, I don't know what the implications are, but it's a good accident :)
>
> Anyways, what should I do for v4? Drop is_endbr6() check or keep it?
Given the current behavior of uprobe overwriting ENDBR64 with INT3, the
is_endbr6() check still makes sense, otherwise is_uprobe_at_func_entry()
would never return true on OSes which have the ENDBR64 compiled in.
However, once userspace IBT actually gets enabled, uprobe should skip
the ENDBR64 and patch the subsequent instruction. Then the is_endbr6()
check would no longer be needed.
--
Josh
Powered by blists - more mailing lists