mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kai Huang <kai.huang@intel.com>
To: dave.hansen@intel.com, bp@alien8.de, tglx@linutronix.de,
	peterz@infradead.org, mingo@redhat.com,
	kirill.shutemov@linux.intel.com
Cc: hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com, seanjc@google.com,
	rick.p.edgecombe@intel.com, reinette.chatre@intel.com,
	isaku.yamahata@intel.com, dan.j.williams@intel.com,
	thomas.lendacky@amd.com, ashish.kalra@amd.com, dwmw@amazon.co.uk,
	bhe@redhat.com, nik.borisov@suse.com, sagis@google.com
Subject: [RFC PATCH 3/5] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum
Date: Thu, 13 Mar 2025 00:34:15 +1300	[thread overview]
Message-ID: <408103f145360dfa04a41bc836ca2c724f29deb0.1741778537.git.kai.huang@intel.com> (raw)
In-Reply-To: <cover.1741778537.git.kai.huang@intel.com>

Some early TDX-capable platforms have an erratum: A kernel partial
write (a write transaction of less than cacheline lands at memory
controller) to TDX private memory poisons that memory, and a subsequent
read triggers a machine check.

On those platforms, the old kernel must reset TDX private memory before
jumping to the new kernel, otherwise the new kernel may see unexpected
machine check.  Currently the kernel doesn't track which page is a TDX
private page.  For simplicity just fail kexec/kdump for those platforms.

Leverage the existing machine_kexec_prepare() to fail kexec/kdump by
adding the check of the presence of the TDX erratum (which is only
checked for if the kernel is built with TDX host support).  This rejects
kexec/kdump when the kernel is loading the kexec/kdump kernel image.

The alternative is to reject kexec/kdump when the kernel is jumping to
the new kernel.  But for kexec this requires adding a new check (e.g.,
arch_kexec_allowed()) in the common code to fail kernel_kexec() at early
stage.  Kdump (crash_kexec()) needs similar check, but it's hard to
justify because crash_kexec() is not supposed to abort.

It's feasible to further relax this limitation, i.e., only fail kexec
when TDX is actually enabled by the kernel.  But this is still a half
measure compared to resetting TDX private memory so just do the simplest
thing for now.

The impact to userspace is the users will get an error when loading the
kexec/kdump kernel image:

  kexec_load failed: Operation not supported

This might be confusing to the users, thus also print the reason in the
dmesg:

  [..] kexec: not allowed on platform with tdx_pw_mce bug.

Signed-off-by: Kai Huang <kai.huang@intel.com>
---
 arch/x86/kernel/machine_kexec_64.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 0e9808eeb63e..e438c4163960 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -311,6 +311,22 @@ int machine_kexec_prepare(struct kimage *image)
 	unsigned long reloc_end = (unsigned long)__relocate_kernel_end;
 	int result;
 
+	/*
+	 * Some early TDX-capable platforms have an erratum.  A kernel
+	 * partial write (a write transaction of less than cacheline
+	 * lands at memory controller) to TDX private memory poisons that
+	 * memory, and a subsequent read triggers a machine check.
+	 *
+	 * On those platforms the old kernel must reset TDX private
+	 * memory before jumping to the new kernel otherwise the new
+	 * kernel may see unexpected machine check.  For simplicity
+	 * just fail kexec/kdump on those platforms.
+	 */
+	if (boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) {
+		pr_info_once("Not allowed on platform with tdx_pw_mce bug\n");
+		return -EOPNOTSUPP;
+	}
+
 	/* Setup the identity mapped 64bit page table */
 	result = init_pgtable(image, __pa(control_page));
 	if (result)
-- 
2.48.1


  parent reply	other threads:[~2025-03-12 11:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12 11:34 [RFC PATCH 0/5] TDX host: kexec/kdump support Kai Huang
2025-03-12 11:34 ` [RFC PATCH 1/5] x86/kexec: Do unconditional WBINVD for bare-metal in stop_this_cpu() Kai Huang
2025-03-13 18:40   ` Edgecombe, Rick P
2025-03-14 10:03     ` Huang, Kai
2025-03-14 15:11     ` Tom Lendacky
2025-03-14 16:28       ` Edgecombe, Rick P
2025-03-14 18:18         ` Tom Lendacky
2025-03-14 18:57           ` Edgecombe, Rick P
2025-03-17 10:11     ` Huang, Kai
2025-03-18  3:41       ` Edgecombe, Rick P
2025-03-20  0:03         ` Huang, Kai
2025-03-17 12:52     ` kirill.shutemov
2025-03-17 21:59       ` Edgecombe, Rick P
2025-03-19 16:41         ` Dave Hansen
2025-03-19 17:03           ` Edgecombe, Rick P
2025-03-19 21:42           ` Huang, Kai
2025-03-12 11:34 ` [RFC PATCH 2/5] x86/kexec: Do unconditional WBINVD for bare-metal in relocate_kernel() Kai Huang
2025-03-13 23:17   ` Edgecombe, Rick P
2025-03-14  9:44     ` Huang, Kai
2025-03-18  3:54       ` Edgecombe, Rick P
2025-03-19  9:57         ` Huang, Kai
2025-03-19 16:20           ` Edgecombe, Rick P
2025-03-12 11:34 ` Kai Huang [this message]
2025-03-12 23:27   ` [RFC PATCH 3/5] x86/kexec: Disable kexec/kdump on platforms with TDX partial write erratum Edgecombe, Rick P
2025-03-13  0:57     ` Huang, Kai
2025-03-13 17:18       ` Edgecombe, Rick P
2025-03-13 22:32         ` Huang, Kai
2025-03-13 22:47           ` Edgecombe, Rick P
2025-03-13 23:57             ` Huang, Kai
2025-03-14 19:03               ` Edgecombe, Rick P
2025-03-17  1:19                 ` Huang, Kai
2025-03-17 23:53                   ` Edgecombe, Rick P
2025-03-12 11:34 ` [RFC PATCH 4/5] x86/virt/tdx: Remove the !KEXEC_CORE dependency Kai Huang
2025-03-12 11:34 ` [RFC PATCH 5/5] x86/virt/tdx: Update the kexec section in the TDX documentation Kai Huang

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=408103f145360dfa04a41bc836ca2c724f29deb0.1741778537.git.kai.huang@intel.com \
    --to=kai.huang@intel.com \
    --cc=ashish.kalra@amd.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=hpa@zytor.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®