linux-kernel - Re: [PATCH v5 0/5] TDX host: kexec() support

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: <26846c6de542b04c2fbee7b8b575b4df6196bac5.camel@intel.com>
Date: Mon, 26 Aug 2024 22:50:02 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "sagis@...gle.com" <sagis@...gle.com>
CC: "Hansen, Dave" <dave.hansen@...el.com>, "luto@...nel.org"
	<luto@...nel.org>, "bp@...en8.de" <bp@...en8.de>, "x86@...nel.org"
	<x86@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>,
	"hpa@...or.com" <hpa@...or.com>, "mingo@...hat.com" <mingo@...hat.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "thomas.lendacky@....com" <thomas.lendacky@....com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 0/5] TDX host: kexec() support

On Mon, 2024-08-26 at 14:22 -0500, Sagi Shahar wrote:
> On Sat, Aug 24, 2024 at 4:31 AM Huang, Kai <kai.huang@...el.com> wrote:
> > 
> > On Fri, 2024-08-23 at 11:15 -0500, Sagi Shahar wrote:
> > > On Mon, Aug 19, 2024 at 5:44 PM Huang, Kai <kai.huang@...el.com> wrote:
> > > > 
> > > > 
> > > > 
> > > > On 20/08/2024 10:28 am, Sagi Shahar wrote:
> > > > > On Mon, Aug 19, 2024 at 5:16 PM Huang, Kai <kai.huang@...el.com> wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 20/08/2024 9:21 am, Sagi Shahar wrote:
> > > > > > > > Currently kexec() support and TDX host are muturally exclusive in the
> > > > > > > > Kconfig.  This series adds the TDX host kexec support so that they can
> > > > > > > > work together and can be enabled at the same time in the Kconfig.
> > > > > > > 
> > > > > > > I tried testing the kexec functionality and noticed that the TDX module
> > > > > > > fails initialization on the second kernel so you can't actually kexec
> > > > > > > between 2 kernels that enable TDX. Is that the expected behavior? Are
> > > > > > > there future patches to enable that functionality?
> > > > > > > 
> > > > > > 
> > > > > > Thanks for testing!
> > > > > > 
> > > > > > Yes this is the expected behaviour.  If the first kernel has enabled
> > > > > > TDX, then the second kernel will fail to init TDX.  The reason the first
> > > > > > SEAMCALL to initialize TDX module in the second kernel will fail due to
> > > > > > module having been initialized.
> > > > > > 
> > > > > > However if the first kernel has not enabled TDX, the second kernel is
> > > > > > able to enable it.
> > > > > 
> > > > > Are there any plans to support both kernels being able to enable TDX
> > > > > in the future? Either by changes to KVM or the TDX module?
> > > > 
> > > > AFAICT we haven't received such requirement so far.  Let me double check
> > > > internally and get back here.
> > > > 
> > > > Btw, if we want to do this purely from software, changing KVM isn't the
> > > > right thing to do.  We need to somehow pass key data structures managing
> > > > TDX module to the second kernel, e.g., module status, locations of
> > > > PAMTs.  And the second kernel needs to be modified to understand those,
> > > > which means some old (second) kernels with TDX support may not be able
> > > > to support this even if we add this to the kernel.
> > > 
> > > Would it be possible to tear down the tdx module and re-initialize it
> > > on the next kernel? I don't think there's a requirement for the tdx
> > > module data structures to remain intact during kexec but it could be
> > > useful if tdx can be enabled on the new kernel.
> > 
> > We discussed this internally.  The TDX module cannot be re-initialized after
> > torn down.  However the new kernel can reload the (same) TDX module and re-
> > initialize it (the P-SEAMLDR supports reload or runtime update TDX module).
> > 
> > However our primary focus is to enable baseline TDX support in upstream.  For
> > TDX host kexec, at this stage we focus on: 1) enable both TDX and Kexec in the
> > Kconfig; 2) allow normal kexec and kdump to work when TDX is enabled.  Making
> > the second kernel be able to use TDX is next-step plan.
> > 
> > May I ask is there any real use case that requires the second kernel to be
> > able to use TDX at this stage?
> 
> [Again in plaintext]
> 
> Right now I don't think we have production requirements for kexec at
> all besides kdump support. Kexec from TDX enabled kernel to a non-TDX
> kernel definitely doesn't have a production requirement.
> 
> It would be nice to be able to kexec to a TDX enabled kernel to speed
> up the development cycle instead of waiting for a full reboot but
> that's not a high priority at the moment.

Yeah agreed.  But then let's do this as a future work after baseline TDX
support is done.