linux-kernel - Re: AMD Memory encryption vs. kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <29e235f7-add2-47ae-b06e-a717202c4faf@amd.com>
Date:   Tue, 28 Nov 2023 08:03:02 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Borislav Petkov <bp@...en8.de>,
        "Shutemov, Kirill" <kirill.shutemov@...el.com>,
        Ashish Kalra <ashish.kalra@....com>,
        Kai Huang <kai.huang@...el.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: AMD Memory encryption vs. kexec

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.