On Tue, Aug 10, 2021 at 02:48:54PM -0500, Tom Lendacky wrote:
> On 8/10/21 1:45 PM, Kuppuswamy, Sathyanarayanan wrote:
> >
> >
> > On 7/27/21 3:26 PM, Tom Lendacky wrote:
> >> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> >> index de01903c3735..cafed6456d45 100644
> >> --- a/arch/x86/kernel/head64.c
> >> +++ b/arch/x86/kernel/head64.c
> >> @@ -19,7 +19,7 @@
> >> #include <linux/start_kernel.h>
> >> #include <linux/io.h>
> >> #include <linux/memblock.h>
> >> -#include <linux/mem_encrypt.h>
> >> +#include <linux/protected_guest.h>
> >> #include <linux/pgtable.h>
> >> #include <asm/processor.h>
> >> @@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long
> >> physaddr,
> >> * there is no need to zero it after changing the memory encryption
> >> * attribute.
> >> */
> >> - if (mem_encrypt_active()) {
> >> + if (prot_guest_has(PATTR_MEM_ENCRYPT)) {
> >> vaddr = (unsigned long)__start_bss_decrypted;
> >> vaddr_end = (unsigned long)__end_bss_decrypted;
> >
> >
> > Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT with
> > prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in
> > TDX.
>
> This is a direct replacement for now.
With current implementation of prot_guest_has() for TDX it breaks boot for
me.
Looking at code agains, now I *think* the reason is accessing a global
variable from __startup_64() inside TDX version of prot_guest_has().
__startup_64() is special. If you access any global variable you need to
use fixup_pointer(). See comment before __startup_64().
I'm not sure how you get away with accessing sme_me_mask directly from
there. Any clues? Maybe just a luck and complier generates code just right
for your case, I donno.
A separate point is that TDX version of prot_guest_has() relies on
cpu_feature_enabled() which is not ready at this point.
I think __bss_decrypted fixup has to be done if sme_me_mask is non-zero.
Or just do it uncoditionally because it's NOP for sme_me_mask == 0.
> I think the change you're requesting
> should be done as part of the TDX support patches so it's clear why it is
> being changed.
>
> But, wouldn't TDX still need to do something with this shared/unencrypted
> area, though? Or since it is shared, there's actually nothing you need to
> do (the bss decrpyted section exists even if CONFIG_AMD_MEM_ENCRYPT is not
> configured)?
AFAICS, only kvmclock uses __bss_decrypted. We don't enable kvmclock in
TDX at the moment. It may change in the future.
--
Kirill A. Shutemov
