From: Fuad Tabba <tabba@google.com>
To: Chao Peng <chao.p.peng@linux.intel.com>
Cc: Sean Christopherson <seanjc@google.com>,
David Hildenbrand <david@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, linux-doc@vger.kernel.org,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
Hugh Dickins <hughd@google.com>, Jeff Layton <jlayton@kernel.org>,
"J . Bruce Fields" <bfields@fieldses.org>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>, Mike Rapoport <rppt@kernel.org>,
Steven Price <steven.price@arm.com>,
"Maciej S . Szmigiero" <mail@maciej.szmigiero.name>,
Vlastimil Babka <vbabka@suse.cz>,
Vishal Annapurve <vannapurve@google.com>,
Yu Zhang <yu.c.zhang@linux.intel.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com,
ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com,
dhildenb@redhat.com, Quentin Perret <qperret@google.com>,
Michael Roth <michael.roth@amd.com>,
mhocko@suse.com, Muchun Song <songmuchun@bytedance.com>,
wei.w.wang@intel.com, Will Deacon <will@kernel.org>,
Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd
Date: Mon, 26 Sep 2022 16:51:44 +0100 [thread overview]
Message-ID: <CA+EHjTz5yGhsxUug+wqa9hrBO60Be0dzWeWzX00YtNxin2eYHg@mail.gmail.com> (raw)
In-Reply-To: <20220926142330.GC2658254@chaop.bj.intel.com>
Hi,
On Mon, Sep 26, 2022 at 3:28 PM Chao Peng <chao.p.peng@linux.intel.com> wrote:
>
> On Fri, Sep 23, 2022 at 04:19:46PM +0100, Fuad Tabba wrote:
> > > Regarding pKVM's use case, with the shim approach I believe this can be done by
> > > allowing userspace mmap() the "hidden" memfd, but with a ton of restrictions
> > > piled on top.
> > >
> > > My first thought was to make the uAPI a set of KVM ioctls so that KVM could tightly
> > > tightly control usage without taking on too much complexity in the kernel, but
> > > working through things, routing the behavior through the shim itself might not be
> > > all that horrific.
> > >
> > > IIRC, we discarded the idea of allowing userspace to map the "private" fd because
> > > things got too complex, but with the shim it doesn't seem _that_ bad.
> > >
> > > E.g. on the memfd side:
> > >
> > > 1. The entire memfd must be mapped, and at most one mapping is allowed, i.e.
> > > mapping is all or nothing.
> > >
> > > 2. Acquiring a reference via get_pfn() is disallowed if there's a mapping for
> > > the restricted memfd.
> > >
> > > 3. Add notifier hooks to allow downstream users to further restrict things.
> > >
> > > 4. Disallow splitting VMAs, e.g. to force userspace to munmap() everything in
> > > one shot.
> > >
> > > 5. Require that there are no outstanding references at munmap(). Or if this
> > > can't be guaranteed by userspace, maybe add some way for userspace to wait
> > > until it's ok to convert to private? E.g. so that get_pfn() doesn't need
> > > to do an expensive check every time.
> > >
> > > static int memfd_restricted_mmap(struct file *file, struct vm_area_struct *vma)
> > > {
> > > if (vma->vm_pgoff)
> > > return -EINVAL;
> > >
> > > if ((vma->vm_end - vma->vm_start) != <file size>)
> > > return -EINVAL;
> > >
> > > mutex_lock(&data->lock);
> > >
> > > if (data->has_mapping) {
> > > r = -EINVAL;
> > > goto err;
> > > }
> > > list_for_each_entry(notifier, &data->notifiers, list) {
> > > r = notifier->ops->mmap_start(notifier, ...);
> > > if (r)
> > > goto abort;
> > > }
> > >
> > > notifier->ops->mmap_end(notifier, ...);
> > > mutex_unlock(&data->lock);
> > > return 0;
> > >
> > > abort:
> > > list_for_each_entry_continue_reverse(notifier &data->notifiers, list)
> > > notifier->ops->mmap_abort(notifier, ...);
> > > err:
> > > mutex_unlock(&data->lock);
> > > return r;
> > > }
> > >
> > > static void memfd_restricted_close(struct vm_area_struct *vma)
> > > {
> > > mutex_lock(...);
> > >
> > > /*
> > > * Destroy the memfd and disable all future accesses if there are
> > > * outstanding refcounts (or other unsatisfied restrictions?).
> > > */
> > > if (<outstanding references> || ???)
> > > memfd_restricted_destroy(...);
> > > else
> > > data->has_mapping = false;
> > >
> > > mutex_unlock(...);
> > > }
> > >
> > > static int memfd_restricted_may_split(struct vm_area_struct *area, unsigned long addr)
> > > {
> > > return -EINVAL;
> > > }
> > >
> > > static int memfd_restricted_mapping_mremap(struct vm_area_struct *new_vma)
> > > {
> > > return -EINVAL;
> > > }
> > >
> > > Then on the KVM side, its mmap_start() + mmap_end() sequence would:
> > >
> > > 1. Not be supported for TDX or SEV-SNP because they don't allow adding non-zero
> > > memory into the guest (after pre-boot phase).
> > >
> > > 2. Be mutually exclusive with shared<=>private conversions, and is allowed if
> > > and only if the entire gfn range of the associated memslot is shared.
> >
> > In general I think that this would work with pKVM. However, limiting
> > private<->shared conversions to the granularity of a whole memslot
> > might be difficult to handle in pKVM, since the guest doesn't have the
> > concept of memslots. For example, in pKVM right now, when a guest
> > shares back its restricted DMA pool with the host it does so at the
> > page-level. pKVM would also need a way to make an fd accessible again
> > when shared back, which I think isn't possible with this patch.
>
> But does pKVM really want to mmap/munmap a new region at the page-level,
> that can cause VMA fragmentation if the conversion is frequent as I see.
> Even with a KVM ioctl for mapping as mentioned below, I think there will
> be the same issue.
pKVM doesn't really need to unmap the memory. What is really important
is that the memory is not GUP'able. Having private memory mapped and
then accessed by a misbehaving/malicious process will reinject a fault
into the misbehaving process.
Cheers,
/fuad
> >
> > You were initially considering a KVM ioctl for mapping, which might be
> > better suited for this since KVM knows which pages are shared and
> > which ones are private. So routing things through KVM might simplify
> > things and allow it to enforce all the necessary restrictions (e.g.,
> > private memory cannot be mapped). What do you think?
> >
> > Thanks,
> > /fuad
next prev parent reply other threads:[~2022-09-26 16:57 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-15 14:29 [PATCH v8 0/8] KVM: mm: fd-based approach for supporting KVM Chao Peng
2022-09-15 14:29 ` [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd Chao Peng
2022-09-19 9:12 ` David Hildenbrand
2022-09-19 19:10 ` Sean Christopherson
2022-09-21 21:10 ` Andy Lutomirski
2022-09-22 13:23 ` Wang, Wei W
2022-09-23 15:20 ` Fuad Tabba
2022-09-23 15:19 ` Fuad Tabba
2022-09-26 14:23 ` Chao Peng
2022-09-26 15:51 ` Fuad Tabba [this message]
2022-09-27 22:47 ` Sean Christopherson
2022-09-30 16:19 ` Fuad Tabba
2022-10-13 13:34 ` Chao Peng
2022-10-17 10:31 ` Fuad Tabba
2022-10-17 14:58 ` Chao Peng
2022-10-17 19:05 ` Fuad Tabba
2022-10-19 13:30 ` Chao Peng
2022-10-18 0:33 ` Sean Christopherson
2022-10-19 15:04 ` Fuad Tabba
2022-09-23 0:58 ` Kirill A . Shutemov
2022-09-26 10:35 ` David Hildenbrand
2022-09-26 14:48 ` Kirill A. Shutemov
2022-09-26 14:53 ` David Hildenbrand
2022-09-27 23:23 ` Sean Christopherson
2022-09-28 13:36 ` Kirill A. Shutemov
2022-09-22 13:26 ` Wang, Wei W
2022-09-22 19:49 ` Sean Christopherson
2022-09-23 0:53 ` Kirill A . Shutemov
2022-09-23 15:20 ` Fuad Tabba
2022-09-30 16:14 ` Fuad Tabba
2022-09-30 16:23 ` Kirill A . Shutemov
2022-10-03 7:33 ` Fuad Tabba
2022-10-03 11:01 ` Kirill A. Shutemov
2022-10-04 15:39 ` Fuad Tabba
2022-10-06 8:50 ` Fuad Tabba
2022-10-06 13:04 ` Kirill A. Shutemov
2022-10-17 13:00 ` Vlastimil Babka
2022-10-17 16:19 ` Kirill A . Shutemov
2022-10-17 16:39 ` Gupta, Pankaj
2022-10-17 21:56 ` Kirill A . Shutemov
2022-10-18 13:42 ` Vishal Annapurve
2022-10-19 15:32 ` Kirill A . Shutemov
2022-10-20 10:50 ` Vishal Annapurve
2022-10-21 13:54 ` Chao Peng
2022-10-21 16:53 ` Sean Christopherson
2022-10-19 12:23 ` Vishal Annapurve
2022-10-21 13:47 ` Chao Peng
2022-10-21 16:18 ` Sean Christopherson
2022-10-24 14:59 ` Kirill A . Shutemov
2022-10-24 15:26 ` David Hildenbrand
2022-11-03 16:27 ` Vishal Annapurve
2022-09-15 14:29 ` [PATCH v8 2/8] KVM: Extend the memslot to support fd-based private memory Chao Peng
2022-09-16 9:14 ` Bagas Sanjaya
2022-09-16 9:53 ` Chao Peng
2022-09-26 10:26 ` Fuad Tabba
2022-09-26 14:04 ` Chao Peng
2022-09-29 22:45 ` Isaku Yamahata
2022-09-29 23:22 ` Sean Christopherson
2022-10-05 13:04 ` Jarkko Sakkinen
2022-10-05 22:05 ` Jarkko Sakkinen
2022-10-06 9:00 ` Fuad Tabba
2022-10-06 14:58 ` Jarkko Sakkinen
2022-10-06 15:07 ` Jarkko Sakkinen
2022-10-06 15:34 ` Sean Christopherson
2022-10-07 11:14 ` Jarkko Sakkinen
2022-10-07 14:58 ` Sean Christopherson
2022-10-07 21:54 ` Jarkko Sakkinen
2022-10-08 16:15 ` Jarkko Sakkinen
2022-10-08 17:35 ` Jarkko Sakkinen
2022-10-10 8:25 ` Chao Peng
2022-10-12 8:14 ` Jarkko Sakkinen
2022-09-15 14:29 ` [PATCH v8 3/8] KVM: Add KVM_EXIT_MEMORY_FAULT exit Chao Peng
2022-09-16 9:17 ` Bagas Sanjaya
2022-09-16 9:54 ` Chao Peng
2022-09-15 14:29 ` [PATCH v8 4/8] KVM: Use gfn instead of hva for mmu_notifier_retry Chao Peng
2022-09-15 14:29 ` [PATCH v8 5/8] KVM: Register/unregister the guest private memory regions Chao Peng
2022-09-26 10:36 ` Fuad Tabba
2022-09-26 14:07 ` Chao Peng
2022-10-11 9:48 ` Fuad Tabba
2022-10-12 2:35 ` Chao Peng
2022-10-17 10:15 ` Fuad Tabba
2022-10-17 22:17 ` Sean Christopherson
2022-10-19 13:23 ` Chao Peng
2022-10-19 15:02 ` Fuad Tabba
2022-10-19 16:09 ` Sean Christopherson
2022-10-19 18:32 ` Fuad Tabba
2022-09-15 14:29 ` [PATCH v8 6/8] KVM: Update lpage info when private/shared memory are mixed Chao Peng
2022-09-29 16:52 ` Isaku Yamahata
2022-09-30 8:59 ` Chao Peng
2022-09-15 14:29 ` [PATCH v8 7/8] KVM: Handle page fault for private memory Chao Peng
2022-10-14 18:57 ` Sean Christopherson
2022-10-17 14:48 ` Chao Peng
2022-09-15 14:29 ` [PATCH v8 8/8] KVM: Enable and expose KVM_MEM_PRIVATE Chao Peng
2022-10-04 14:55 ` Jarkko Sakkinen
2022-10-10 8:31 ` Chao Peng
2022-10-06 8:55 ` Fuad Tabba
2022-10-10 8:33 ` Chao Peng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+EHjTz5yGhsxUug+wqa9hrBO60Be0dzWeWzX00YtNxin2eYHg@mail.gmail.com \
--to=tabba@google.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=bp@alien8.de \
--cc=chao.p.peng@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=ddutile@redhat.com \
--cc=dhildenb@redhat.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=jlayton@kernel.org \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=jun.nakajima@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mail@maciej.szmigiero.name \
--cc=maz@kernel.org \
--cc=mhocko@suse.com \
--cc=michael.roth@amd.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qperret@google.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=steven.price@arm.com \
--cc=tglx@linutronix.de \
--cc=vannapurve@google.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=wei.w.wang@intel.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yu.c.zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).