linux-kernel - Re: [PATCH v2 2/5] x86/kexec: do unconditional WBINVD in relocate

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]

Date: Thu, 21 Mar 2024 01:10:47 +0200
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: "Huang, Kai" <kai.huang@...el.com>, 
	Tom Lendacky <thomas.lendacky@....com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, dave.hansen@...el.com, 
	bp@...en8.de, tglx@...utronix.de, mingo@...hat.com, hpa@...or.com, 
	luto@...nel.org, peterz@...radead.org, rick.p.edgecombe@...el.com, 
	ashish.kalra@....com, chao.gao@...el.com, bhe@...hat.com, nik.borisov@...e.com, 
	pbonzini@...hat.com, seanjc@...gle.com
Subject: Re: [PATCH v2 2/5] x86/kexec: do unconditional WBINVD in
 relocate_kernel()

On Thu, Mar 21, 2024 at 09:48:28AM +1300, Huang, Kai wrote:
> 
> > > Hi Tom,
> > > 
> > > I am not aware of kexec() support status for SEV-ES/SEV-SNP guests.
> > > Does patch 1 break them?
> > 
> > SNP guests can kexec with some patches that are currently in process
> > around shared to private memory conversions. ES guests can only kexec
> > with a single vCPU. There was a recent patch series to add support for
> > multiple vCPUs.
> > 
> > Patch #1 doesn't break either ES or SNP because we still have an IDT and
> > traditional kernel addressing in place, so the #VC can be handled.
> 
> How about plain SEV guest?
> 
> > 
> > Whereas patch #2 has switched to identity mapping and removed the IDT,
> > so a #VC causes a triple fault.
> 
> That makes sense.  Thanks.
> 
> Hi Kirill,
> 
> Does TDX guest have similar behaviour -- that WBINVD in stop_this_cpu() can
> be handled although it causes #VE, while WBINVD in relocate_kernel() will
> just triple fault the guest?

No. We never handle WBINVD #VE. Guest cannot handle WBINVD itself and the
only option is to ask host to do this. We cannot guarantee host will do
anything useful with the request. I guess it can be potential attack
vector if host strategically ignores WBINVD to induce bad guest behaviour.

And it is not good from host PoV either. If it does WBINVD on every guest
request we get guest->host DoS attack possibility.

Tom, I am curious, how do you deal with these problems?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov