Re: x86 entry perf unwinding failure (missing IRET_REGS annotation on stack switch?)

[Josh Poimboeuf]

On Tue, Apr 28, 2020 at 02:46:27PM +0200, Peter Zijlstra wrote:
> > I'm thinking something like this should fix it.  Peter, does this look
> > ok?
> 
> Unfortunate. But also, I fear, insufficient. Specifically consider
> things like:
> 
> 	ALTERNATIVE "jmp 1f",
> 		"alt...
> 		"..."
> 		"...insn", X86_FEAT_foo
> 	1:
> 
> This results in something like:
> 
> 
> 	.text	.altinstr_replacement
> 	e8 xx	...
> 	90
> 	90
> 	...
> 	90
> 
> Where all our normal single byte nops (0x90) are unreachable with
> undefined CFI, but the alternative might have CFI, which is never
> propagated.
> 
> We ran into this with the validate_alternative stuff from Alexandre.

I don't get what you're saying.  We decided not to allow CFI changes in
alternatives.  And how does this relate to my patch?

> > @@ -773,12 +772,26 @@ static int handle_group_alt(struct objtool_file *file,
> >  	struct instruction *last_orig_insn, *last_new_insn, *insn, *fake_jump = NULL;
> >  	unsigned long dest_off;
> >  
> > +	/*
> > +	 * For uaccess checking, propagate the STAC/CLAC from the alternative
> > +	 * to the original insn to avoid paths where we see the STAC but then
> > +	 * take the NOP instead of CLAC (and vice versa).
> > +	 */
> > +	if (!orig_insn->ignore_alts && orig_insn->type == INSN_NOP &&
> > +	    *new_insn &&
> > +	    ((*new_insn)->type == INSN_STAC ||
> > +	     (*new_insn)->type == INSN_CLAC))
> > +		orig_insn->type = (*new_insn)->type;
> 
> Also, this generates a mis-match between actual instruction text and
> type. We now have a single byte instruction (0x90) with the type of a 3
> byte (SLAC/CLAC). Which currently isn't a problem, but I'm looking at
> adding infrastructure for having objtool rewrite instructions.

But it doesn't actually change the original instruction bytes, it just
changes the decoding.  Is that really going to be a problem?  We do that
in other places as well, and it helps simplify code flow.

Also might I ask why you're going to be rewriting instructions?  That
sounds scary.

> So rather than hacking around this issue, should we not make
> create_orc() smarter?

Maybe, though I don't see how that logic belongs in create_orc().  It
might be tricky distinguishing between normal undefined and "undefined
because of a skip_orig".  Right now create_orc() is blissfully ignorant.

-- 
Josh