linux-kernel - Re: [PATCH 8/8] x86/retpoline: Fix retpoline unwind

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: <20200428183028.GB13575@hirez.programming.kicks-ass.net>
Date:   Tue, 28 Apr 2020 20:30:28 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     alexandre.chartre@...cle.com, linux-kernel@...r.kernel.org,
        jthierry@...hat.com, tglx@...utronix.de, x86@...nel.org,
        mbenes@...e.cz
Subject: Re: [PATCH 8/8] x86/retpoline: Fix retpoline unwind

On Fri, Apr 24, 2020 at 02:30:28PM -0500, Josh Poimboeuf wrote:
> On Thu, Apr 23, 2020 at 02:47:25PM +0200, Peter Zijlstra wrote:
> >  .macro CALL_NOSPEC reg:req
> >  #ifdef CONFIG_RETPOLINE
> > -	ANNOTATE_NOSPEC_ALTERNATIVE
> > -	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; call *%\reg),\
> > -		__stringify(RETPOLINE_CALL %\reg), X86_FEATURE_RETPOLINE,\
> > -		__stringify(lfence; ANNOTATE_RETPOLINE_SAFE; call *%\reg), X86_FEATURE_RETPOLINE_AMD
> > +	/*
> > +	 * This cannot be ALTERNATIVE_2 like with JMP_NOSPEC, because ORC
> > +	 * unwind data is alternative invariant and needs stack modifying
> > +	 * instructions to be in the same place for all alternatives.
> > +	 *
> > +	 * IOW the CALL instruction must be at the same offset for all cases.
> > +	 */
> > +	ALTERNATIVE "", "lfence", X86_FEATURE_RETPOLINE_AMD
> > +	ALTERNATIVE __stringify(ANNOTATE_RETPOLINE_SAFE; call *%\reg), \
> > +		    __stringify(call __x86_retpoline_\reg), X86_FEATURE_RETPOLINE
> 
> I'm missing why ALTERNATIVE_2 wouldn't work here.  How is the call a
> "stack modifying instruction"?  It's not an intra-function call so it
> shouldn't affect ORC at all, right?

My bad. I find it hard not to consider CALL a stack modification. Let me
fix that.