linux-kernel - Re: [PATCH v2 07/10] KVM: x86: Always populate L1 GPA for KVM_MAP

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: <Zh2xPwGAMMgqKeYV@google.com>
Date: Mon, 15 Apr 2024 15:59:11 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Kai Huang <kai.huang@...el.com>, 
	"federico.parola@...ito.it" <federico.parola@...ito.it>, 
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "dmatlack@...gle.com" <dmatlack@...gle.com>, 
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "michael.roth@....com" <michael.roth@....com>
Subject: Re: [PATCH v2 07/10] KVM: x86: Always populate L1 GPA for KVM_MAP_MEMORY

On Mon, Apr 15, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-04-15 at 14:17 -0700, Sean Christopherson wrote:
> > > But doesn't the fault handler need the vCPU state?
> > 
> > Ignoring guest MTRRs, which will hopefully soon be a non-issue, no.  There are
> > only six possible roots if TDP is enabled:
> > 
> >       1. 4-level !SMM !guest_mode
> >       2. 4-level  SMM !guest_mode
> >       3. 5-level !SMM !guest_mode
> >       4. 5-level  SMM !guest_mode
> >       5. 4-level !SMM guest_mode
> >       6. 5-level !SMM guest_mode
> > 
> > 4-level vs. 5-level is a guest MAXPHYADDR thing, and swapping the MMU
> > eliminates the SMM and guest_mode issues.  If there is per-vCPU state that
> > makes its way into the TDP page tables, then we have problems, because it
> > means that there is per-vCPU state in per-VM structures that isn't
> > accounted for.
> > 
> > There are a few edge cases where KVM treads carefully, e.g. if the fault is
> > to the vCPU's APIC-access page, but KVM manually handles those to avoid
> > consuming per-vCPU state.
> > 
> > That said, I think this option is effectively 1b, because dropping the SMM
> > vs.  guest_mode state has the same uAPI problems as forcibly swapping the
> > MMU, it's just a different way of doing so.
> > 
> > The first question to answer is, do we want to return an error or
> > "silently" install mappings for !SMM, !guest_mode.  And so this option
> > becomes relevant only _if_ we want to unconditionally install mappings for
> > the 'base" mode.
> 
> Ah, I thought there was some logic around CR0.CD.

There is, but it's hopefully going the way of the dodo, along with full MTRR
virtualization:

https://lore.kernel.org/all/20240309010929.1403984-1-seanjc@google.com