| 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
| ||
|
Message-ID: <aDbdjmRceMLs1RPN@yzhao56-desk.sh.intel.com>
Date: Wed, 28 May 2025 17:55:26 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
CC: Ackerley Tng <ackerleytng@...gle.com>, <kvm@...r.kernel.org>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
<linux-fsdevel@...r.kernel.org>, <aik@....com>, <ajones@...tanamicro.com>,
<akpm@...ux-foundation.org>, <amoorthy@...gle.com>,
<anthony.yznaga@...cle.com>, <anup@...infault.org>, <aou@...s.berkeley.edu>,
<bfoster@...hat.com>, <brauner@...nel.org>, <catalin.marinas@....com>,
<chao.p.peng@...el.com>, <chenhuacai@...nel.org>, <dave.hansen@...el.com>,
<david@...hat.com>, <dmatlack@...gle.com>, <dwmw@...zon.co.uk>,
<erdemaktas@...gle.com>, <fan.du@...el.com>, <fvdl@...gle.com>,
<graf@...zon.com>, <haibo1.xu@...el.com>, <hch@...radead.org>,
<hughd@...gle.com>, <ira.weiny@...el.com>, <isaku.yamahata@...el.com>,
<jack@...e.cz>, <james.morse@....com>, <jarkko@...nel.org>, <jgg@...pe.ca>,
<jgowans@...zon.com>, <jhubbard@...dia.com>, <jroedel@...e.de>,
<jthoughton@...gle.com>, <jun.miao@...el.com>, <kai.huang@...el.com>,
<keirf@...gle.com>, <kent.overstreet@...ux.dev>, <kirill.shutemov@...el.com>,
<liam.merwick@...cle.com>, <maciej.wieczor-retman@...el.com>,
<mail@...iej.szmigiero.name>, <maz@...nel.org>, <mic@...ikod.net>,
<michael.roth@....com>, <mpe@...erman.id.au>, <muchun.song@...ux.dev>,
<nikunj@....com>, <nsaenz@...zon.es>, <oliver.upton@...ux.dev>,
<palmer@...belt.com>, <pankaj.gupta@....com>, <paul.walmsley@...ive.com>,
<pbonzini@...hat.com>, <pdurrant@...zon.co.uk>, <peterx@...hat.com>,
<pgonda@...gle.com>, <pvorel@...e.cz>, <qperret@...gle.com>,
<quic_cvanscha@...cinc.com>, <quic_eberman@...cinc.com>,
<quic_mnalajal@...cinc.com>, <quic_pderrin@...cinc.com>,
<quic_pheragu@...cinc.com>, <quic_svaddagi@...cinc.com>,
<quic_tsoni@...cinc.com>, <richard.weiyang@...il.com>,
<rick.p.edgecombe@...el.com>, <rientjes@...gle.com>, <roypat@...zon.co.uk>,
<rppt@...nel.org>, <seanjc@...gle.com>, <shuah@...nel.org>,
<steven.price@....com>, <steven.sistare@...cle.com>,
<suzuki.poulose@....com>, <tabba@...gle.com>, <thomas.lendacky@....com>,
<usama.arif@...edance.com>, <vannapurve@...gle.com>, <vbabka@...e.cz>,
<viro@...iv.linux.org.uk>, <vkuznets@...hat.com>, <wei.w.wang@...el.com>,
<will@...nel.org>, <willy@...radead.org>, <xiaoyao.li@...el.com>,
<yilun.xu@...el.com>, <yuzenghui@...wei.com>, <zhiquan1.li@...el.com>
Subject: Re: [RFC PATCH v2 06/51] KVM: Query guest_memfd for private/shared
status
On Wed, May 28, 2025 at 04:08:34PM +0800, Binbin Wu wrote:
>
>
> On 5/27/2025 11:55 AM, Yan Zhao wrote:
> > On Wed, May 14, 2025 at 04:41:45PM -0700, Ackerley Tng wrote:
> > > Query guest_memfd for private/shared status if those guest_memfds
> > > track private/shared status.
> > >
> > > With this patch, Coco VMs can use guest_memfd for both shared and
> > > private memory. If Coco VMs choose to use guest_memfd for both
> > > shared and private memory, by creating guest_memfd with the
> > > GUEST_MEMFD_FLAG_SUPPORT_SHARED flag, guest_memfd will be used to
> > > provide the private/shared status of the memory, instead of
> > > kvm->mem_attr_array.
> > >
> > > Change-Id: I8f23d7995c12242aa4e09ccf5ec19360e9c9ed83
> > > Signed-off-by: Ackerley Tng <ackerleytng@...gle.com>
> > > ---
> > > include/linux/kvm_host.h | 19 ++++++++++++-------
> > > virt/kvm/guest_memfd.c | 22 ++++++++++++++++++++++
> > > 2 files changed, 34 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > > index b317392453a5..91279e05e010 100644
> > > --- a/include/linux/kvm_host.h
> > > +++ b/include/linux/kvm_host.h
> > > @@ -2508,12 +2508,22 @@ static inline void kvm_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
> > > }
> > > #ifdef CONFIG_KVM_GMEM_SHARED_MEM
> > > +
> > > bool kvm_gmem_memslot_supports_shared(const struct kvm_memory_slot *slot);
> > > +bool kvm_gmem_is_private(struct kvm_memory_slot *slot, gfn_t gfn);
> > > +
> > > #else
> > > +
> > > static inline bool kvm_gmem_memslot_supports_shared(const struct kvm_memory_slot *slot)
> > > {
> > > return false;
> > > }
> > > +
> > > +static inline bool kvm_gmem_is_private(struct kvm_memory_slot *slot, gfn_t gfn)
> > > +{
> > > + return false;
> > > +}
> > > +
> > > #endif /* CONFIG_KVM_GMEM_SHARED_MEM */
> > > #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> > > @@ -2544,13 +2554,8 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> > > return false;
> > > slot = gfn_to_memslot(kvm, gfn);
> > > - if (kvm_slot_has_gmem(slot) && kvm_gmem_memslot_supports_shared(slot)) {
> > > - /*
> > > - * For now, memslots only support in-place shared memory if the
> > > - * host is allowed to mmap memory (i.e., non-Coco VMs).
> > > - */
> > > - return false;
> > > - }
> > > + if (kvm_slot_has_gmem(slot) && kvm_gmem_memslot_supports_shared(slot))
> > > + return kvm_gmem_is_private(slot, gfn);
> > When userspace gets an exit reason KVM_EXIT_MEMORY_FAULT, looks it needs to
> > update both KVM memory attribute and gmem shareability, via two separate ioctls?
> IIUC, when userspace sets flag GUEST_MEMFD_FLAG_SUPPORT_SHARED to create the
> guest_memfd, the check for memory attribute will go through the guest_memfd way,
> the information in kvm->mem_attr_array will not be used.
>
> So if userspace sets GUEST_MEMFD_FLAG_SUPPORT_SHARED, it uses
> KVM_GMEM_CONVERT_SHARED/PRIVATE to update gmem shareability.
> If userspace doesn't set GUEST_MEMFD_FLAG_SUPPORT_SHARED, it still uses
> KVM_SET_MEMORY_ATTRIBUTES to update KVM memory attribute tracking.
Ok, so the user needs to search the memory region and guest_memfd to choose the
right ioctl.
For slots with guest_memfd of flag GUEST_MEMFD_FLAG_SUPPORT_SHARED, the
KVM_LPAGE_MIXED_FLAG bit in the lpage_info cannot reflect the truth and a false
value there may also prevent KVM from installing a huge page.
> >
> >
> > > return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
> > > }
>
>
Powered by blists - more mailing lists