Re: AMD Memory encryption vs. kexec

From: Tom Lendacky
Date: Tue Nov 28 2023 - 09:03:14 EST


On 11/27/23 18:00, Dave Hansen wrote:
... actually cc'd the mailing lists and x86@ exploder on this one.
Please reply here.

---

There are two kexec-related wbinvd's:

One for the kexec boot CPU in relocate_kernel() which is driven by
CC_ATTR_HOST_MEM_ENCRYPT:

image->start = relocate_kernel((unsigned long)image->head,
(unsigned long)page_list,
image->start,
image->preserve_context,
cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT));

the other is for non-boot CPUs in stop_this_cpu():

if (c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0)))
native_wbinvd();

By my reading, the CC_ATTR_HOST_MEM_ENCRYPT is basically a check for
whether the current kernel has enabled SME but not SEV while the
stop_this_cpu() site is driven purely by whether the hardware *supports*
SME.

The whole supposed reason stop_this_cpu() checks CPUID directly is that
the current kernel SME/SEV enabling might not match the _next_ kernel's
enabling choices.

Correct.


So, why is a _current_ kernel check OK for relocate_kernel(), but not OK
for stop_this_cpu()?

The relocate_kernel() check provides an indication of whether SME is actually active. The kexec kernel is placed in unencrypted memory to match how the system was booted - where the kernel is loaded into unencrypted memory and then encrypted in-place if SME is desired (mem_encrypt=on). Since the kexec kernel will be unencrypted, the cc_platform_has() call is used to indicate whether to perform a wbinvd to remove encrypted cache line entries. If SME is not active, then there is no need to flush caches prior to booting the kexec kernel.

With SEV, the kernel is loaded encrypted from the start and so the kexec kernel can remain in encrypted memory and no wbinvd is required.

Thanks,
Tom


It seems to me like both sites might need to use the
stop_this_cpu()-style "raw" hardware support checks.

Why do I care? TDX potentially needs wbinvd at the same two spots. It
would be nice to have a common cc_attr for both sites, but I need to
reconcile the apparently disparate AMD uses first.