On Tue, Feb 27, 2024 at 10:09:06AM +0100, Greg KH wrote: > On Tue, Feb 27, 2024 at 12:56:38AM -0800, Pawan Gupta wrote: > > On Tue, Feb 27, 2024 at 09:21:33AM +0100, Jiri Slaby wrote: > > > On 27. 02. 24, 9:00, Pawan Gupta wrote: > > > > This is the backport of recently upstreamed series that moves VERW > > > > execution to a later point in exit-to-user path. This is needed because > > > > in some cases it may be possible for data accessed after VERW executions > > > > may end into MDS affected CPU buffers. Moving VERW closer to ring > > > > transition reduces the attack surface. > > > > > > > > Patch 1/6 includes a minor fix that is queued for upstream: > > > > https://lore.kernel.org/lkml/170899674562.398.6398007479766564897.tip-bot2@tip-bot2/ > > > > > > Ah, you note it here. > > > > > > But you should include this patch on its own instead of merging it to 1/6. > > > > Thats exactly what I would have done ideally, but the backports to > > stable kernels < 6.6 wont work without this patch. And this patch is > > going to take some time before it can be merged upstream. > > It's in the tip-urgent branch, doesn't that mean it will go to Linus > this week? If it's in linux-next, and you _KNOW_ it will go to Linus > this week, and the git id is stable, then we can consider the > application of it to the stable tree now. If we use the approach in Nikolay's backport, we can avoid dependency on any other patch. Basically alternative patching jmp instead of VERW: +.macro CLEAR_CPU_BUFFERS + ALTERNATIVE "jmp .Lskip_verw_\@", "", X86_FEATURE_CLEAR_CPU_BUF + verw _ASM_RIP(mds_verw_sel) +.Lskip_verw_\@: +.endm https://lore.kernel.org/stable/20240226122237.198921-3-nik.borisov@xxxxxxxx/ I will send the backports with this approach.
