linux-kernel - Re: [RFC PATCH 1/8] KVM: Document 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: <ZepiU1x7i-ksI28A@google.com>
Date: Thu, 7 Mar 2024 16:56:51 -0800
From: David Matlack <dmatlack@...gle.com>
To: "Huang, Kai" <kai.huang@...el.com>
Cc: Isaku Yamahata <isaku.yamahata@...ux.intel.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"federico.parola@...ito.it" <federico.parola@...ito.it>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
	"michael.roth@....com" <michael.roth@....com>,
	"seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [RFC PATCH 1/8] KVM: Document KVM_MAP_MEMORY ioctl

On 2024-03-08 01:20 PM, Huang, Kai wrote:
> > > > +:Parameters: struct kvm_memory_mapping(in/out)
> > > > +:Returns: 0 on success, <0 on error
> > > > +
> > > > +KVM_MAP_MEMORY populates guest memory without running vcpu.
> > > > +
> > > > +::
> > > > +
> > > > +  struct kvm_memory_mapping {
> > > > +	__u64 base_gfn;
> > > > +	__u64 nr_pages;
> > > > +	__u64 flags;
> > > > +	__u64 source;
> > > > +  };
> > > > +
> > > > +  /* For kvm_memory_mapping:: flags */
> > > > +  #define KVM_MEMORY_MAPPING_FLAG_WRITE         _BITULL(0)
> > > > +  #define KVM_MEMORY_MAPPING_FLAG_EXEC          _BITULL(1)
> > > > +  #define KVM_MEMORY_MAPPING_FLAG_USER          _BITULL(2)
> > > 
> > > I am not sure what's the good of having "FLAG_USER"?
> > > 
> > > This ioctl is called from userspace, thus I think we can just treat this always
> > > as user-fault?
> > 
> > The point is how to emulate kvm page fault as if vcpu caused the kvm page
> > fault.  Not we call the ioctl as user context.
> 
> Sorry I don't quite follow.  What's wrong if KVM just append the #PF USER
> error bit before it calls into the fault handler?
> 
> My question is, since this is ABI, you have to tell how userspace is
> supposed to use this.  Maybe I am missing something, but I don't see how
> USER should be used here.

If we restrict this API to the TDP MMU then KVM_MEMORY_MAPPING_FLAG_USER
is meaningless, PFERR_USER_MASK is only relevant for shadow paging.

KVM_MEMORY_MAPPING_FLAG_WRITE seems useful to allow memslots to be
populated with writes (which avoids just faulting in the zero-page for
anon or tmpfs backed memslots), while also allowing populating read-only
memslots.

I don't really see a use-case for KVM_MEMORY_MAPPING_FLAG_EXEC.