linux-kernel - Re: [PATCH v11 09/35] KVM: x86: Determine shared/private faults based on vm

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: <20240212164759.35cb7gds4p2inprg@amd.com>
Date: Mon, 12 Feb 2024 10:47:59 -0600
From: Michael Roth <michael.roth@....com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Paolo Bonzini <pbonzini@...hat.com>, <kvm@...r.kernel.org>,
	<linux-coco@...ts.linux.dev>, <linux-mm@...ck.org>,
	<linux-crypto@...r.kernel.org>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <tglx@...utronix.de>, <mingo@...hat.com>,
	<jroedel@...e.de>, <thomas.lendacky@....com>, <hpa@...or.com>,
	<ardb@...nel.org>, <vkuznets@...hat.com>, <jmattson@...gle.com>,
	<luto@...nel.org>, <dave.hansen@...ux.intel.com>, <slp@...hat.com>,
	<pgonda@...gle.com>, <peterz@...radead.org>,
	<srinivas.pandruvada@...ux.intel.com>, <rientjes@...gle.com>,
	<dovmurik@...ux.ibm.com>, <tobin@....com>, <bp@...en8.de>, <vbabka@...e.cz>,
	<kirill@...temov.name>, <ak@...ux.intel.com>, <tony.luck@...el.com>,
	<sathyanarayanan.kuppuswamy@...ux.intel.com>, <alpergun@...gle.com>,
	<jarkko@...nel.org>, <ashish.kalra@....com>, <nikunj.dadhania@....com>,
	<pankaj.gupta@....com>, <liam.merwick@...cle.com>, <zhi.a.wang@...el.com>
Subject: Re: [PATCH v11 09/35] KVM: x86: Determine shared/private faults
 based on vm_type

On Mon, Feb 12, 2024 at 08:27:21AM -0800, Sean Christopherson wrote:
> On Mon, Feb 12, 2024, Paolo Bonzini wrote:
> > On Sat, Dec 30, 2023 at 6:24 PM Michael Roth <michael.roth@....com> wrote:
> > >
> > > For KVM_X86_SNP_VM, only the PFERR_GUEST_ENC_MASK flag is needed to
> > > determine with an #NPF is due to a private/shared access by the guest.
> > > Implement that handling here. Also add handling needed to deal with
> > > SNP guests which in some cases will make MMIO accesses with the
> > > encryption bit.
> > >
> > > Signed-off-by: Michael Roth <michael.roth@....com>
> > > ---
> > >  arch/x86/kvm/mmu/mmu.c          | 12 ++++++++++--
> > >  arch/x86/kvm/mmu/mmu_internal.h | 20 +++++++++++++++++++-
> > >  2 files changed, 29 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > > index d3fbfe0686a0..61213f6648a1 100644
> > > --- a/arch/x86/kvm/mmu/mmu.c
> > > +++ b/arch/x86/kvm/mmu/mmu.c
> > > @@ -4331,6 +4331,7 @@ static int kvm_faultin_pfn_private(struct kvm_vcpu *vcpu,
> > >  static int __kvm_faultin_pfn(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
> > >  {
> > >         struct kvm_memory_slot *slot = fault->slot;
> > > +       bool private_fault = fault->is_private;
> > 
> > I think it's nicer to just make the fault !is_private in
> > kvm_mmu_do_page_fault().
> 
> Yeah.  I'm starting to recall more of this discussion.  This is one of the reasons
> I suggested/requested stuffing the error code to piggy-back the new SNP bit; doing
> so allows is_private to be computed from the get-go without needing any vendor
> specific hooks.

Makes sense to me. Based on your suggestion here:

  https://lore.kernel.org/kvm/ZcUO5sFEAIH68JIA@google.com/

I was planning to drop this patch and adopt the TDX implementation:

  https://github.com/intel/tdx/commit/3717a903ef453aa7b62e7eb65f230566b7f158d4

-Mike