On Sat, Oct 21, 2023 at 12:50:37AM +0100, Andrew Cooper wrote: > On 20/10/2023 9:44 pm, Pawan Gupta wrote: > > diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h > > index c55cc243592e..e1b623a27e1b 100644 > > --- a/arch/x86/include/asm/nospec-branch.h > > +++ b/arch/x86/include/asm/nospec-branch.h > > @@ -111,6 +111,24 @@ > > #define RESET_CALL_DEPTH_FROM_CALL > > #endif > > > > +/* > > + * Macro to execute VERW instruction to mitigate transient data sampling > > + * attacks such as MDS. On affected systems a microcode update overloaded VERW > > + * instruction to also clear the CPU buffers. > > + * > > + * Note: Only the memory operand variant of VERW clears the CPU buffers. To > > + * handle the case when VERW is executed after user registers are restored, use > > + * RIP to point the memory operand to a part NOPL instruction that contains > > + * __KERNEL_DS. > > + */ > > +#define __EXEC_VERW(m) verw _ASM_RIP(m) > > + > > +#define EXEC_VERW \ > > + __EXEC_VERW(551f); \ > > + /* nopl __KERNEL_DS(%rax) */ \ > > + .byte 0x0f, 0x1f, 0x80, 0x00, 0x00; \ > > +551: .word __KERNEL_DS; \ > > + > > Is this actually wise from a perf point of view? > > You're causing a data access to the instruction stream, and not only > that, the immediate next instruction. Some parts don't take kindly to > snoops hitting L1I. > > A better option would be to simply have > > .section .text.entry > .align CACHELINE > mds_verw_sel: > .word __KERNEL_DS > int3 > .align CACHELINE > > > And then just have EXEC_VERW be > > verw mds_verw_sel(%rip) ALTERNATIVE "", "verw mds_verw_sel(%rip)", X86_FEATURE_USER_CLEAR_CPU_BUF But yeah, his seems like the sanest form.
