Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <32be2ea4-b60b-fbca-10c2-8c06f5bc135b@maciej.szmigiero.name>
Date:   Wed, 20 Jul 2022 02:01:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Content-Language: en-US
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     linux-kernel@vger.kernel.org, keescook@chromium.org,
        hjl.tools@gmail.com, andrew.cooper3@citrix.com,
        mark.rutland@arm.com, will@kernel.org, ndesaulniers@google.com,
        x86@kernel.org, Ankur Arora <ankur.a.arora@oracle.com>
References: <20211204134338.760603010@infradead.org>
 <20211204134908.140103474@infradead.org>
 <9011132e-d78b-8bec-10cb-2b3d77a4e1fc@maciej.szmigiero.name>
 <Ytcguqp+/aTiOcnN@worktop.programming.kicks-ass.net>
 <YtcjEEpfvYmvHjmE@worktop.programming.kicks-ass.net>
From:   "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Subject: Re: [RFC][PATCH] x86,nospec: Simplify {JMP,CALL}_NOSPEC
In-Reply-To: <YtcjEEpfvYmvHjmE@worktop.programming.kicks-ass.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 19.07.2022 23:33, Peter Zijlstra wrote:
> On Tue, Jul 19, 2022 at 11:23:07PM +0200, Peter Zijlstra wrote:
>> Subject: x86,nospec: Simplify {JMP,CALL}_NOSPEC
>>
>> Have {JMP,CALL}_NOSPEC generate the same code GCC does for indirect
>> calls and rely on the objtool retpoline patching infrastructure.
>>
>> There's no reason these should be alternatives while the vast bulk of
>> compiler generated retpolines are not.
>>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> ---
>>   arch/x86/include/asm/nospec-branch.h | 24 ++++++++++++++++++------
>>   1 file changed, 18 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
>> index 10a3bfc1eb23..7bb319d2932c 100644
>> --- a/arch/x86/include/asm/nospec-branch.h
>> +++ b/arch/x86/include/asm/nospec-branch.h
>> @@ -93,6 +93,19 @@
>>   #endif
>>   .endm
>>   
>> +/*
>> + * Equivalent to -mindirect-branch-cs-prefix; emit the 5 byte jmp/call
>> + * to the retpoline thunk with a CS prefix when the register requires
>> + * a RAX prefix byte to encode. Also see apply_alternatives().
> 
> Obviously I meant: apply_retpolines() ...

Will apply_retpolines() actually patch in that trailing int3 in
the X86_FEATURE_RETPOLINE_LFENCE case?

Looking at its code it uses just ordinary NOPs as fill:
> 	/*
> 	 * For RETPOLINE_LFENCE: prepend the indirect CALL/JMP with an LFENCE.
> 	 */
> 	if (cpu_feature_enabled(X86_FEATURE_RETPOLINE_LFENCE)) {
> 		bytes[i++] = 0x0f;
> 		bytes[i++] = 0xae;
> 		bytes[i++] = 0xe8; /* LFENCE */
> 	}
> 
> 	ret = emit_indirect(op, reg, bytes + i);
> 	if (ret < 0)
> 		return ret;
> 	i += ret;
> 
> 	for (; i < insn->length;)
> 		bytes[i++] = BYTES_NOP1;

BYTES_NOP1 is 0x90.

>> + */
>> +.macro __CS_PREFIX reg:req
>> +	.irp rs,r8,r9,r10,r11,r12,r13,r14,r15
>> +	.ifc \reg,\rs
>> +	.byte 0x2e
>> +	.endif
>> +	.endr
>> +.endm
>> +
>>   /*
>>    * JMP_NOSPEC and CALL_NOSPEC macros can be used instead of a simple
>>    * indirect jmp/call which may be susceptible to the Spectre variant 2
>> @@ -100,19 +113,18 @@
>>    */
>>   .macro JMP_NOSPEC reg:req
>>   #ifdef CONFIG_RETPOLINE
>> -	ALTERNATIVE_2 __stringify(ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), \
>> -		      __stringify(jmp __x86_indirect_thunk_\reg), X86_FEATURE_RETPOLINE, \
>> -		      __stringify(lfence; ANNOTATE_RETPOLINE_SAFE; jmp *%\reg), X86_FEATURE_RETPOLINE_LFENCE
>> +	__CS_PREFIX \reg
>> +	jmp	__x86_indirect_thunk_\reg
>>   #else
>>   	jmp	*%\reg
>> +	int3
>>   #endif

Perhaps that int3 should be here to be common to both
"#ifdef CONFIG_RETPOLINE" branches?

>>   .endm
>>   

Thanks,
Maciej