linux-kernel - Re: x86 entry perf unwinding failure (missing IRET

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

Message-ID: <20200428163327.br43qcontatbrxlf@treble>
Date:   Tue, 28 Apr 2020 11:33:27 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Jann Horn <jannh@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        alexandre.chartre@...cle.com
Subject: Re: x86 entry perf unwinding failure (missing IRET_REGS annotation
 on stack switch?)

On Tue, Apr 28, 2020 at 09:25:51AM -0700, Sean Christopherson wrote:
> On Tue, Apr 28, 2020 at 10:54:13AM -0500, Josh Poimboeuf wrote:
> > On Tue, Apr 28, 2020 at 10:49:09AM -0500, Josh Poimboeuf wrote:
> > > On Tue, Apr 28, 2020 at 05:25:52PM +0200, Peter Zijlstra wrote:
> > > > On Tue, Apr 28, 2020 at 09:31:57AM -0500, Josh Poimboeuf wrote:
> > > > > That's quite the monstrosity, and I still don't see the point.  I
> > > > > thought we decided to just disallow CFI changes in alternatives anyway?
> > > > > That can be done much simpler.
> > > > 
> > > > Something like so then ?
> > > > 
> > > > ---
> > > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > > > index 8443ec690051..d14d83e6edb0 100644
> > > > --- a/tools/objtool/check.c
> > > > +++ b/tools/objtool/check.c
> > > > @@ -940,6 +940,7 @@ static int handle_group_alt(struct objtool_file *file,
> > > >  
> > > >  		last_new_insn = insn;
> > > >  
> > > > +		insn->alt_group = true;
> > > >  		insn->ignore = orig_insn->ignore_alts;
> > > >  		insn->func = orig_insn->func;
> > > >  
> > > > @@ -2242,6 +2243,11 @@ static int handle_insn_ops(struct instruction *insn, struct insn_state *state)
> > > >  	list_for_each_entry(op, &insn->stack_ops, list) {
> > > >  		int res;
> > > >  
> > > > +		if (insn->alt_group) {
> > > > +			WARN_FUNC("alternative has CFI", insn->sec, insn->offset);
> > > > +			return 1;
> > > > +		}
> > > > +
> > > 
> > > ACK (separate patch)
> > 
> > BTW, since most people don't know what CFI is, how about something like
> > 
> > 	"unsupported stack change in alternatives code"
> 
> Would it be accurate to print
> 
> 	"unsupported CFI stack change in alternatives code"?
> 
> to give the developer something more explicit to plug into their search
> engine?

I don't have a strong opinion either way, though this warning is going
to be documented in stack-validation.txt anyway right Peter? :-)

-- 
Josh