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@xxxxxxxx/
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@xxxxxxxxxxxxxxx/T/
https://lore.kernel.org/stable/20240226-delay-verw-backport-6-1-y-v1-0-b3a2c5b9b0cb@xxxxxxxxxxxxxxx/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
