linux-kernel - Re: [PATCHv3 10/14] x86/tdx: Convert shared memory back to private on 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: <20231121095859.36xiltn2gwgyxmwy@box.shutemov.name>
Date:   Tue, 21 Nov 2023 12:58:59 +0300
From:   "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
To:     "Huang, Kai" <kai.huang@...el.com>
Cc:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "Hunter, Adrian" <adrian.hunter@...el.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "ashish.kalra@....com" <ashish.kalra@....com>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "bhe@...hat.com" <bhe@...hat.com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>
Subject: Re: [PATCHv3 10/14] x86/tdx: Convert shared memory back to private
 on kexec

On Tue, Nov 21, 2023 at 03:46:41AM +0000, Huang, Kai wrote:
> 
> >  
> > +static atomic_t conversions_in_progress;
> > +static bool conversion_allowed = true;
> > 
> 
> [...]
> 
> >  /* Used while preparing memory map entries for second kernel */
> >  struct crash_memmap_data {
> > @@ -107,6 +108,9 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
> >  
> >  	crash_smp_send_stop();
> >  
> > +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT))
> > +		x86_platform.guest.enc_kexec_unshare_mem(true);
> > +
> >  	cpu_emergency_disable_virtualization();
> >  
> >  	/*
> > diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> > index 830425e6d38e..9fb302562bfd 100644
> > --- a/arch/x86/kernel/reboot.c
> > +++ b/arch/x86/kernel/reboot.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/delay.h>
> >  #include <linux/objtool.h>
> >  #include <linux/pgtable.h>
> > +#include <linux/kexec.h>
> >  #include <acpi/reboot.h>
> >  #include <asm/io.h>
> >  #include <asm/apic.h>
> > @@ -31,6 +32,7 @@
> >  #include <asm/realmode.h>
> >  #include <asm/x86_init.h>
> >  #include <asm/efi.h>
> > +#include <asm/tdx.h>
> >  
> >  /*
> >   * Power off function, if any
> > @@ -716,6 +718,9 @@ static void native_machine_emergency_restart(void)
> >  
> >  void native_machine_shutdown(void)
> >  {
> > +	if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT) && kexec_in_progress)
> > +		x86_platform.guest.enc_kexec_unshare_mem(false);
> > +
> >  	/* Stop the cpus and apics */
> >  #ifdef CONFIG_X86_IO_APIC
> >  	/*
> 
> In native_machine_crash_shutdown() the "unshare" is called after
> crash_smp_send_stop(), but here it's called before the stop_other_cpus().
> 
> I am wondering if you call "unshare" after stop_other_cpus(), can we guarantee
> there's only one cpu running in both normal and crash kexec in which case you
> might be able to get rid of the "conversions_in_progress" and
> "conversion_allowed" above?

For normal kexec we need to keep other CPUs going so they can finish
conversion cleanly and get us to the known state. Note that the conversion
is not atomic wrt preemption.

In crash scenario we do the best effort: detect if we race with conversion
and report. We cannot really wait for conversions to finish: we get into
crash path with IRQs disabled and in generally unknown state.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov