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-aa17b... https://lore.kernel.org/stable/20240226-delay-verw-backport-6-1-y-v1-0-b3a2c...
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,