All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	tony.luck@intel.com, ak@linux.intel.com,
	tim.c.chen@linux.intel.com
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	kvm@vger.kernel.org,
	Alyssa Milburn <alyssa.milburn@linux.intel.com>,
	Daniel Sneddon <daniel.sneddon@linux.intel.com>,
	antonio.gomez.iglesias@linux.intel.com,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Subject: [PATCH  2/6] x86/entry_64: Add VERW just before userspace transition
Date: Fri, 20 Oct 2023 13:45:03 -0700	[thread overview]
Message-ID: <20231020-delay-verw-v1-2-cff54096326d@linux.intel.com> (raw)
In-Reply-To: <20231020-delay-verw-v1-0-cff54096326d@linux.intel.com>

Mitigation for MDS is to use VERW instruction to clear any secrets in
CPU Buffers. Any memory accesses after VERW execution can still remain
in CPU buffers. It is safer to execute VERW late in return to user path
to minimize the window in which kernel data can end up in CPU buffers.
There are not many kernel secrets to be had after SWITCH_TO_USER_CR3.

Add support for deploying VERW mitigation after user register state is
restored. This helps minimize the chances of kernel data ending up into
CPU buffers after executing VERW.

Note that the mitigation at the new location is not yet enabled.

Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
---
 arch/x86/entry/entry_64.S        | 14 ++++++++++++++
 arch/x86/entry/entry_64_compat.S |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 43606de22511..e72ac30f0714 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -223,6 +223,8 @@ syscall_return_via_sysret:
 SYM_INNER_LABEL(entry_SYSRETQ_unsafe_stack, SYM_L_GLOBAL)
 	ANNOTATE_NOENDBR
 	swapgs
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
 	sysretq
 SYM_INNER_LABEL(entry_SYSRETQ_end, SYM_L_GLOBAL)
 	ANNOTATE_NOENDBR
@@ -663,6 +665,10 @@ SYM_INNER_LABEL(swapgs_restore_regs_and_return_to_usermode, SYM_L_GLOBAL)
 	/* Restore RDI. */
 	popq	%rdi
 	swapgs
+
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
+
 	jmp	.Lnative_iret
 
 
@@ -774,6 +780,9 @@ native_irq_return_ldt:
 	 */
 	popq	%rax				/* Restore user RAX */
 
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
+
 	/*
 	 * RSP now points to an ordinary IRET frame, except that the page
 	 * is read-only and RSP[31:16] are preloaded with the userspace
@@ -1502,6 +1511,9 @@ nmi_restore:
 	std
 	movq	$0, 5*8(%rsp)		/* clear "NMI executing" */
 
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
+
 	/*
 	 * iretq reads the "iret" frame and exits the NMI stack in a
 	 * single instruction.  We are returning to kernel mode, so this
@@ -1520,6 +1532,8 @@ SYM_CODE_START(ignore_sysret)
 	UNWIND_HINT_END_OF_STACK
 	ENDBR
 	mov	$-ENOSYS, %eax
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
 	sysretl
 SYM_CODE_END(ignore_sysret)
 #endif
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 70150298f8bd..d2ccd9148239 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -271,6 +271,8 @@ SYM_INNER_LABEL(entry_SYSRETL_compat_unsafe_stack, SYM_L_GLOBAL)
 	xorl	%r9d, %r9d
 	xorl	%r10d, %r10d
 	swapgs
+	/* Mitigate CPU data sampling attacks .e.g. MDS */
+	USER_CLEAR_CPU_BUFFERS
 	sysretl
 SYM_INNER_LABEL(entry_SYSRETL_compat_end, SYM_L_GLOBAL)
 	ANNOTATE_NOENDBR

-- 
2.34.1



  parent reply	other threads:[~2023-10-20 20:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 20:44 [PATCH 0/6] Delay VERW Pawan Gupta
2023-10-20 20:44 ` [PATCH 1/6] x86/bugs: Add asm helpers for executing VERW Pawan Gupta
2023-10-20 23:13   ` Sean Christopherson
2023-10-21  1:00     ` Pawan Gupta
2023-10-20 23:55   ` [RESEND][PATCH " Andrew Cooper
2023-10-21  1:18     ` Pawan Gupta
2023-10-21  1:33       ` Andrew Cooper
2023-10-21  2:21         ` Pawan Gupta
2023-10-23 18:08           ` Josh Poimboeuf
2023-10-23 19:09             ` Pawan Gupta
2023-10-25  6:28     ` Pawan Gupta
2023-10-25  7:22       ` Peter Zijlstra
2023-10-25  7:52         ` Andrew Cooper
2023-10-25  8:02           ` Peter Zijlstra
2023-10-25 15:27         ` Pawan Gupta
     [not found]   ` <6439a094-23a6-4de3-aa41-bd033163e044@citrix.com>
2023-10-22 16:16     ` [PATCH " Peter Zijlstra
2023-10-20 20:45 ` Pawan Gupta [this message]
2023-10-23 18:22   ` [PATCH 2/6] x86/entry_64: Add VERW just before userspace transition Josh Poimboeuf
2023-10-23 19:13     ` Pawan Gupta
2023-10-23 19:17     ` Dave Hansen
2023-10-23 18:35   ` Josh Poimboeuf
2023-10-23 21:04     ` Pawan Gupta
2023-10-23 21:47       ` Josh Poimboeuf
2023-10-23 22:30         ` Pawan Gupta
2023-10-23 22:45           ` Dave Hansen
2023-10-24  0:00             ` Pawan Gupta
2023-10-20 20:45 ` [PATCH 3/6] x86/entry_32: " Pawan Gupta
2023-10-20 23:49   ` Andi Kleen
2023-10-21  1:28     ` Pawan Gupta
2023-10-20 20:45 ` [PATCH 4/6] x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key Pawan Gupta
2023-10-23 18:48   ` Josh Poimboeuf
2023-10-23 21:09     ` Pawan Gupta
2023-10-20 20:45 ` [PATCH 5/6] x86/bugs: Cleanup mds_user_clear Pawan Gupta
2023-10-23  8:51   ` Nikolay Borisov
2023-10-23 16:06     ` Pawan Gupta
2023-10-20 20:45 ` [PATCH 6/6] KVM: VMX: Move VERW closer to VMentry for MDS mitigation Pawan Gupta
2023-10-20 22:55   ` Sean Christopherson
2023-10-21  0:46     ` Pawan Gupta
2023-10-23 14:58       ` Sean Christopherson
2023-10-23 17:05         ` Pawan Gupta
2023-10-23 18:56   ` Josh Poimboeuf
2023-10-23 21:17     ` Pawan Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231020-delay-verw-v1-2-cff54096326d@linux.intel.com \
    --to=pawan.kumar.gupta@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=alyssa.milburn@linux.intel.com \
    --cc=antonio.gomez.iglesias@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.