Re: [PATCH 6.7.y 1/6] x86/bugs: Add asm helpers for executing VERW

[Jiri Slaby <jirislaby@kernel.org>]

On 27. 02. 24, 9:27, Pawan Gupta wrote:
> On Tue, Feb 27, 2024 at 08:40:26AM +0100, Jiri Slaby wrote:
>> ...
>>> --- a/arch/x86/include/asm/nospec-branch.h
>>> +++ b/arch/x86/include/asm/nospec-branch.h
>>> @@ -315,6 +315,17 @@
>>>    #endif
>>>    .endm
>>> +/*
>>> + * Macro to execute VERW instruction that mitigate transient data sampling
>>> + * attacks such as MDS. On affected systems a microcode update overloaded VERW
>>> + * instruction to also clear the CPU buffers. VERW clobbers CFLAGS.ZF.
>>> + *
>>> + * Note: Only the memory operand variant of VERW clears the CPU buffers.
>>> + */
>>> +.macro CLEAR_CPU_BUFFERS
>>> +	ALTERNATIVE "", __stringify(verw mds_verw_sel), X86_FEATURE_CLEAR_CPU_BUF
>>
>> Why is not rip-relative preserved here?
> 
> Because Nikolay reported that it was creating a problem for backports on
> kernels that don't support relocations in alternatives. More on this
> here:
> 
>    https://lore.kernel.org/lkml/20558f89-299b-472e-9a96-171403a83bd6@suse.com/

Sure, I know about the issue.

> Also, RIP-relative addressing was a requirement only for the initial
> versions of the series, where the VERW operand was pointing within the
> macro. For performance gains, later versions switched to the
> implementation in which all VERW sites were pointing to single memory
> location. With that, RIP-relative addressing could be droped in favor of
> fixed addresses.
> 
>> Will this work at all (it looks like verw would now touch random
>> memory)?
> 
> AFAIK, all memory operand variants of VERW have the CPU buffer clearing
> behavior. I will confirm this with the CPU architects.

I might be too dumb to understand this, so sorry if the below does not 
make sense. Neither I cannot see "why it works" in the minor patch you 
sent (and incorporated here). You only explain it's easier for backports 
and "was needed in earlier versions".

But verw can #PF (and actually used to before Nik invented the jmp 
workaround in the SUSE backport). I assume it's the case when the store 
of the segment (mds_verw_sel) cannot be accessed/read. Now, with fixed 
addressing this works unless KASLR is employed. If it is, the fixed 
address of mds_verw_sel no longer points to the correct memory. Or what 
am I missing?

>> In any way, should you do any changes during the backport, you shall
>> document that.
> 
> Sorry, I missed to mention this change in 6.7.y backport. I did include
> this info in the other backports I sent:
> 
>    https://lore.kernel.org/stable/20240226-delay-verw-backport-6-6-y-v1-0-aa17b2922725@linux.intel.com/T/
>    https://lore.kernel.org/stable/20240226-delay-verw-backport-6-1-y-v1-0-b3a2c5b9b0cb@linux.intel.com/T/

I am sure you are aware you need NOT doing this very change in 6.6 and 
6.7 ;). It somehow confused me too.

thanks,
-- 
js
suse labs