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: <CAAhR5DFrOaXDbndFOSWAfdu-79buSR2ki_AU=z68FcHmn9o4Ow@mail.gmail.com>
Date: Fri, 23 Aug 2024 11:15:15 -0500
From: Sagi Shahar <sagis@...gle.com>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: "bp@...en8.de" <bp@...en8.de>, "Hansen, Dave" <dave.hansen@...el.com>, "hpa@...or.com" <hpa@...or.com>, 
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "luto@...nel.org" <luto@...nel.org>, 
	"mingo@...hat.com" <mingo@...hat.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"peterz@...radead.org" <peterz@...radead.org>, "seanjc@...gle.com" <seanjc@...gle.com>, 
	"tglx@...utronix.de" <tglx@...utronix.de>, "thomas.lendacky@....com" <thomas.lendacky@....com>, 
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v5 0/5] TDX host: kexec() support

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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ