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: <20200428141457.4il3bgjjhifs47zc@treble>
Date:   Tue, 28 Apr 2020 09:14:57 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     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 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