linux-kernel - Re: [RFC][PATCH] x86,nospec: Simplify {JMP,CALL}

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]

Date:   Wed, 20 Jul 2022 02:01:39 +0200
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, keescook@...omium.org,
        hjl.tools@...il.com, andrew.cooper3@...rix.com,
        mark.rutland@....com, will@...nel.org, ndesaulniers@...gle.com,
        x86@...nel.org, Ankur Arora <ankur.a.arora@...cle.com>
Subject: Re: [RFC][PATCH] x86,nospec: Simplify {JMP,CALL}_NOSPEC

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@...radead.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