linux-kernel - Re: [PATCH] objtool: Fix STACK_FRAME_NON

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 5 May 2022 00:42:14 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] objtool: Fix STACK_FRAME_NON_STANDARD reloc type

On Mon, 2 May 2022 10:59:21 -0700
Josh Poimboeuf <jpoimboe@...hat.com> wrote:

> On Sat, Apr 30, 2022 at 01:44:00PM +0200, Peter Zijlstra wrote:
> > > > I also don't see any kprobe/optprobe hooks in unwind.h, so what happens
> > > > if we hit an optprobe?
> > > 
> > > Same as for any other generated code, the unwinder will try to fall back
> > > to frame pointers, and if that doesn't work, the unwind stops.
> > > 
> > > That commit didn't change anything since it was already not being
> > > directly executed anyway, but rather used to generate code on the fly.

Ah, OK. So ORC will not work on the dynamically generated trampoline code.
Can we generate ORC information entry dynamically?
(E.g. copying ORC data from the original code)

> > > 
> > > And before that commit it was being ignored by ORC anyway, thanks to
> > > STACK_FRAME_NON_STANDARD.  Which can now be removed since this code is
> > > now data and objtool will no longer try to understand it.
> > 
> > Right; but I suppose I'm wondering if we should fix this. It seems a
> > rather sub-optimal state of affairs.
> 
> Masami recently fixed some kprobes ORC issues but I don't know if this
> one was fixed.

I've fixed the kretprobe ORC unwinder issue. I need to check the optprobe
case too.

> 
> As to the whether it's worth fixing, I dunno.  There are trade offs.
> 
> Depends on how common the stack trace is -- I'm guessing not very, since
> I've never seen a bug report -- and how important it is to get to full
> ORC coverage.  If our goal is full coverage, we'd need a way for
> generated code to add/remove ORC entries.

Agreed, if I can copy the ORC entries for the original code to the entries
for generated code, I can fix it.

Thank you,


> 
> -- 
> Josh
> 


-- 
Masami Hiramatsu <mhiramat@...nel.org>