[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220226114847.GB11184@worktop.programming.kicks-ass.net>
Date: Sat, 26 Feb 2022 12:48:47 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: x86@...nel.org, joao@...rdrivepizza.com, hjl.tools@...il.com,
jpoimboe@...hat.com, andrew.cooper3@...rix.com,
linux-kernel@...r.kernel.org, ndesaulniers@...gle.com,
keescook@...omium.org, samitolvanen@...gle.com,
mark.rutland@....com, alyssa.milburn@...el.com, mbenes@...e.cz,
rostedt@...dmis.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH v2 15/39] x86/ibt,kprobes: Fix more +0 assumptions
On Sat, Feb 26, 2022 at 11:10:40AM +0900, Masami Hiramatsu wrote:
> > The alternative 'hack' I've been contemplating is (ab)using
> > INT_MIN/INT_MAX offset for __fentry__ and __fexit__ points (that latter
> > is something we'll probably have to grow when CET-SHSTK or backward-edge
> > CFI gets to be done, because then ROP tricks as used by function-graph
> > and kretprobes are out the window).
> >
> > That way sym+[0..size) is still a valid reference to the actual
> > instruction in the symbol, but sym+INT_MIN will hard map to __fentry__
> > while sym+INT_MAX will get us __fexit__.
>
> Interesting, is that done by another series?
Not yet, that was just a crazy idea I had ;-)
Powered by blists - more mailing lists