linux-kernel - Re: [PATCH v2 9/9] objtool: Abstract unwind hint reading

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: <20200831195546.gt72y5tplwuftqv7@treble>
Date:   Mon, 31 Aug 2020 14:55:46 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Julien Thierry <jthierry@...hat.com>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org, mbenes@...e.cz,
        raphael.gault@....com, benh@...nel.crashing.org
Subject: Re: [PATCH v2 9/9] objtool: Abstract unwind hint reading

On Tue, Aug 25, 2020 at 01:31:46PM +0100, Julien Thierry wrote:
> > > > The call to update_cfi_state_regs() is really regs-specific, not
> > > > sp-specific.
> > > > 
> > > 
> > > I must admit I don't really understand what "regs" is and why exactly such
> > > an exception in stack state tracking is made where only operations to SP are
> > > taken into account.
> > 
> > "regs" is a special type of stack frame, usually for asm entry code,
> > where the frame is actually an instance of 'struct pt_regs'.  So if
> > there's a variable associated it with it, maybe it should have "regs" in
> > the name.
> > 
> > Though I think non-x86 arches will also have regs frames, so would it
> > make sense to just make the unwind hint types a global multiarch thing?
> > They could be renamed to UNWIND_HINT_TYPE_REGS{_PARTIAL}.  Then there
> > wouldn't really be a need for the "sp_only" thing.
> > 
> 
> If having regs frame means having a pt_regs on the stack when procedure
> calls/return, then yes this will probably be the case on most archs (it is
> for arm64 at least.

The regs frames aren't for function/procedure calls, but rather
exceptions/interrupts.

> However in that case, arm64 still builds a stack frame and sets the frame
> pointer, so only handling SP operations doesn't make much sense for arm64.

If for example arm64 were to switch to ORC, it could have regs-only
frames in entry code just like x86.

> Also, things like ORC_TYPE_REGS_IRET don't have a use for arm64 (but maybe
> for other non-x86 arches it does?)

If we called it TYPE_REGS_PARTIAL, at least the name would be generic
enough, even if it's not used by all arches.

> In the end that's why I left the unwind hint types as arch defined. It seems
> like every arch will have their specific semantics they might want to let
> objtool know about.

Ok, I guess I'd need to look at the code to have an opinion.  If there
turn out to be commonalities between the different arch unwind hints
then we could always unify them later.

-- 
Josh