From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCB9CC3DA7F for ; Mon, 5 Aug 2024 16:53:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34FAA6B00AA; Mon, 5 Aug 2024 12:53:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 300BF6B00AC; Mon, 5 Aug 2024 12:53:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19FF76B00AE; Mon, 5 Aug 2024 12:53:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EFBCF6B00AA for ; Mon, 5 Aug 2024 12:53:44 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 93E72A6BDD for ; Mon, 5 Aug 2024 16:53:44 +0000 (UTC) X-FDA: 82418788368.17.C14953E Received: from mail-yw1-f202.google.com (mail-yw1-f202.google.com [209.85.128.202]) by imf07.hostedemail.com (Postfix) with ESMTP id CF3C840002 for ; Mon, 5 Aug 2024 16:53:42 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LigQvRnp; spf=pass (imf07.hostedemail.com: domain of 3lQOxZgsKCJw68GANHAUPJCCKKCHA.8KIHEJQT-IIGR68G.KNC@flex--ackerleytng.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3lQOxZgsKCJw68GANHAUPJCCKKCHA.8KIHEJQT-IIGR68G.KNC@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722876774; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=5RINMmanv5d77bAGQFePUMBVazdRsDXA+mtc4C0tc9c=; b=EIoPNIWiniUwxu04ZsQpxLjhdwwbim+CbpoY+1iGuawY/ge+GjhxAL8wXzr+jbFtsEKlqH OzPzJ2MLKrtusKsEheDqEr8N/uWkPSfR/mSzxAm41AnceQoqTEQ4BwTBdWyd7wy2b+Useb cOnvpuDDWBdKJGzDjTfhBW968sz6auw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=LigQvRnp; spf=pass (imf07.hostedemail.com: domain of 3lQOxZgsKCJw68GANHAUPJCCKKCHA.8KIHEJQT-IIGR68G.KNC@flex--ackerleytng.bounces.google.com designates 209.85.128.202 as permitted sender) smtp.mailfrom=3lQOxZgsKCJw68GANHAUPJCCKKCHA.8KIHEJQT-IIGR68G.KNC@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722876774; a=rsa-sha256; cv=none; b=EaiV4c2LcGrEF0KO4F+qn78N5FDGPnXaPJABW5tifCCGGRGreOC/U93I4qNlPWPjhAgoHa Xt7OknyyAKr9NTWClz+AlLiHdmrMHfbu5oPVqDVPJoVWNOVlRZ9aUHBH8gEU2lnlXIv7j8 tJ6QtNUzU/INK/5P8p91UWax+414i+o= Received: by mail-yw1-f202.google.com with SMTP id 00721157ae682-65b985bb059so222619387b3.2 for ; Mon, 05 Aug 2024 09:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722876822; x=1723481622; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=5RINMmanv5d77bAGQFePUMBVazdRsDXA+mtc4C0tc9c=; b=LigQvRnp635y0ljpGddKyeLflC7jighyHBDX8OxTMqq7arHRRj1ccGGKxllsgaG2g7 qXvvWBYsO8+zbjDocOHOTuIBBp9y7OuC4VldlBQc7Llh9bUVClBbzclPE0w26XaB6adh n06Xi0kx0/SDcxeEStFDujjcmzt4huyaoRxzgZJbgxTJfg+e/qIsPk45DB0szHhE807D g95PTSFHNCWreZG+SIRy/w7Eg+pASANp1kGhZRZzNsDttmOEBTdIXcew+u5ATVLujEwV z9pCwyaDvo/xwcfbe+qFM5bvATNcNJbOUA4qZkHlbmaLSAydaEK1uow0YCMsgTnZjnlh x16w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722876822; x=1723481622; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5RINMmanv5d77bAGQFePUMBVazdRsDXA+mtc4C0tc9c=; b=KxJmMrP4brY/M85v7U9/B6Q2KLI80CdoUJ0oBffSdDr9VS50Xboz9I5FMxvSleMyue mnmfkDd5ErDGN6ADh7gBHMk/Umm47SOd1OgwbO9oVZ33CTtfHNNCdwhrupna6b1hIM8n uTljBlf10cGrD82XFNnJzoPh0aLm86NRTr62v1l7Zvv7Atu7RkZiQQY1CGHXs2i27raJ p8+UkDg6Pm/A8WgpFSH7QcCZunJsRs9ttmoQMg89QgSDyaTSTeemCSHW/rMPgVyUJNAl Zw33VYNcEz/hySeVNj8amF0iOEISKj9vmVAWDuE+k6Uam8Q5t26z9C5vzIcW11s1Bj5V jcyw== X-Forwarded-Encrypted: i=1; AJvYcCXXMJRhenv61wZRKbN7kiKXiRCI6R2fESvlKT5SKkegZMChF0FlfDba5g3TjWhYEbKxpyRjO33yB6Eg+nx26p3UZic= X-Gm-Message-State: AOJu0YxoCOGQb3rYmAibpqAt5AuwZovw/+v7UsbmEFnjDxpk/qBC1Yfu BLtCD8QhVWuuILHv6A54Ig2IlX6qacV0m2R/iDetvqZ/6aV44oUeWD2WCGkcJeyGbtZeYczJ+HA sKccGmqm6wzolZt5X1nv5xQ== X-Google-Smtp-Source: AGHT+IHELS7pYbC3Zr7WBPtJ3Cq214iX6+GHHwXiPeaVsTvMZI0On/kcO/ZamF4rcV5eByN04Yo229KkFlFLUH/VmA== X-Received: from ackerleytng-ctop.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:13f8]) (user=ackerleytng job=sendgmr) by 2002:a05:690c:113:b0:648:3f93:61f2 with SMTP id 00721157ae682-689641a414emr4467787b3.6.1722876821677; Mon, 05 Aug 2024 09:53:41 -0700 (PDT) Date: Mon, 05 Aug 2024 16:53:39 +0000 In-Reply-To: <20240801090117.3841080-1-tabba@google.com> (message from Fuad Tabba on Thu, 1 Aug 2024 10:01:07 +0100) Mime-Version: 1.0 Message-ID: Subject: Re: [RFC PATCH v2 00/10] KVM: Restricted mapping of guest_memfd at the host and pKVM/arm64 support From: Ackerley Tng To: Fuad Tabba Cc: kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, seanjc@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, yu.c.zhang@linux.intel.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, tabba@google.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: j5gi9tn7cqfr7sn9xkt11qfw86f7jgoo X-Rspam-User: X-Rspamd-Queue-Id: CF3C840002 X-Rspamd-Server: rspam02 X-HE-Tag: 1722876822-519563 X-HE-Meta: U2FsdGVkX1/X2/uYl84skkUIB3GtmZgxSqyU7WjDwKq6ovQXtu92xv9HDocmhXoj1AMSUPBQQwZICqGKJoHtYPwHN2Lwye59LbHou3bLF4/+aTDNnYiDw+d7AdBC+dAmbbUBHtLTdsBfJu3/w2AkiHrH0OHdXE3wHVL3fV7AN5lk/WuTBhASNhix3y8A0xc/AO6I+lMtIFCYhCYsmieK4ZFzvkeINZH4EKI5IMx4eBGIpVXvd+nkC1KXYNVEHQk0SB3Hkf4Pa6Xf7sfJaqWA+9KyfVon51nbuEL3Ukl3Ccy96JHQhoRN8sW9E5zc9C5HLDJZrv5HtpUk5AF02gnW8Z/iJzeq0QycZL5nfpwduTwUhKDdOu3hUPtwfVjmAIsqJiSUBQR4fk+i56E3T2yWaEkXYgAsZxmA1tVwBUhRS1vLU72AkqBljTQNG29eMIhj4YvVda3jBtF0BDL/1ZaLWRfya3fwMGJyaZENtePen19VgLbspMRgW4OVoSj9kHy34BluW4p1m48KJG5qjMqr/Y+jH1argoQ5+M1s6KUgRVgh5I1Cj3plAGgddEqqvn8brnecOiPaKfgN6KRbFNU+aQJAnLq/V9b9HXLtDKEr04FSVlwkLmCFZlFZ2mV96dPJQO4IMig2/avmF5zPgMlOx1o0p4Dr4YRJKZBKe5Q+r9x5INctvPuv6pHh8oMnW7vtO9y2vPS+OVS29GVIvGguH/sUfsVutJVlNEt0lcWfZ0Qcbet2lQ6dBpW1rIuIccgcig9xJdh4Bc/FR1iun7qigGwytPDieIthQUAQizXLNZ9m92QYzr/lbDiDMJG8IEUuCxLJTgMLmfiu3Ncj4hL0iCv7ZdY6u67MFQmbtmJTByHQUzJaTsa/ioiLyoHlkXNy94Dg40AQTg7ACXlkyN/5qomxY4AP/xh+CiRXccBpFKS0wwpd+OyNLhWAH50HKkGVUoSVlZVEufqUhbeeJy+ sUmZuH4J 1EP0HRDqP5H9ytU/UkqDCENeRZwowqUVvLxSoIBpY+3vIcdRJR3N+/OmFLxr/xfPgVCBJxzTmtgIzLRPy5hHqpquvJ4h3zaCfOoc9kE3TQO3A3U/OlJU/FAQLFcIDLGYOBD1lEXzWRsy93j3GVEWcyRyd8TKI1qx1BvlJzKxu3hHX0qE72V3qCzE2BsKJtR1ACoTkb3hiYLJL8DMYEMpqZ/OSpxzZ+sl7ytM8Citb8srf14FPDM3odobDddHbLcLzyRan5PNmIMqKDssGuJXga9HsH9uK2EVeR3lZIyFDBBvCbJhq2TLF8PQGj0Ul2jjARewJ686fyKbvEjV2D7Ix5m5VoLjMf/BGXNPDFpBCbNnUCaLwIIfKfIX4sBsAFMSDtMYmtj0QN0ZZv+Gs29NwWMfp1wx4nrm0cul8rL0lSpRLpwEeOB9A4r+ek5Dn7xTXCpEljgUc0b8yGs7J2M7vl7CKZIncpdIH4k3orXzEKU2pOxwwOSnqsu+uDcsK8tIlkCGZ4vFG1oaiIlqnLikWlB2s6YWj3sHAIkPg8hd1+k0tQfd5hdYkcRhP0de8olfJ0shxTNz89BW0GxiezXU2AmAqQIC9mrtmbJ0oFBLLwc4go9ohPAFilXsotP0g4116Sd+9d9aNX+XUgqws9Fdi05ZuDqzOff9CP0LjLCbGwEqy/LyKaB0AM1h2k0N7IV3/+CsV5IXj6oYp0X/x6n/hhUcOrReb+/+0GZ1gRsY/b4F1mO4p4KnE3kTIzIqEk/L90DFdAIvyfdeE7+DfX1Hz2rONj692br1ZlnCINT/qYa7qHuw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Fuad Tabba writes: > This series adds restricted mmap() support to guest_memfd, as > well as support for guest_memfd on pKVM/arm64. It is based on > Linux 6.10. > > Main changes since V1 [1]: > > - Decoupled whether guest memory is mappable from KVM memory > attributes (SeanC) > > Mappability is now tracked in the guest_mem object, orthogonal to > whether userspace wants the memory to be private or shared. > Moreover, the memory attributes capability (i.e., > KVM_CAP_MEMORY_ATTRIBUTES) is not enabled for pKVM, since for > software-based hypervisors such as pKVM and Gunyah, userspace is > informed of the state of the memory via hypervisor exits if > needed. > > Even if attributes are enabled, this patch series would still > work (modulo bugs), without compromising guest memory nor > crashing the system. > > - Use page_mapped() instead of page_mapcount() to check if page > is mapped (DavidH) > > - Add a new capability, KVM_CAP_GUEST_MEMFD_MAPPABLE, to query > whether guest private memory can be mapped (with aforementioned > restrictions) > > - Add a selftest to check whether memory is mappable when the > capability is enabled, and not mappable otherwise. Also, test the > effect of punching holes in mapped memory. (DavidH) > > By design, guest_memfd cannot be mapped, read, or written by the > host. In pKVM, memory shared between a protected guest and the I think we should use "cannot be faulted in" to be clear that guest_memfd can be mmaped but not faulted in. Would it be better to have all the variables/config macros be something about faultability instead of mappability? > host is shared in-place, unlike the other confidential computing > solutions that guest_memfd was originally envisaged for (e.g, > TDX). When initializing a guest, as well as when accessing memory > shared by the guest with the host, it would be useful to support > mapping that memory at the host to avoid copying its contents. > > One of the benefits of guest_memfd is that it prevents a > misbehaving host process from crashing the system when attempting > to access (deliberately or accidentally) protected guest memory, > since this memory isn't mapped to begin with. Without > guest_memfd, the hypervisor would still prevent such accesses, > but in certain cases the host kernel wouldn't be able to recover, > causing the system to crash. > > Support for mmap() in this patch series maintains the invariant > that only memory shared with the host, either explicitly by the > guest or implicitly before the guest has started running (in > order to populate its memory) is allowed to have a valid mapping > at the host. At no time should private (as viewed by the > hypervisor) guest memory be mapped at the host. > > This patch series is divided into two parts: > > The first part is to the KVM core code. It adds opt-in support > for mapping guest memory only as long as it is shared. For that, > the host needs to know the mappability status of guest memory. > Therefore, the series adds a structure to track whether memory is > mappable. This new structure is associated with each guest_memfd > object. > > The second part of the series adds guest_memfd support for > pKVM/arm64. > > We don't enforce the invariant that only memory shared with the > host can be mapped by the host userspace in > file_operations::mmap(), but we enforce it in > vm_operations_struct:fault(). On vm_operations_struct::fault(), > we check whether the page is allowed to be mapped. If not, we > deliver a SIGBUS to the current task, as discussed in the Linux > MM Alignment Session on this topic [2]. > > Currently there's no support for huge pages, which is something > we hope to add in the future, and seems to be a hot topic for the > upcoming LPC 2024 [3]. > > Cheers, > /fuad > > [1] https://lore.kernel.org/all/20240222161047.402609-1-tabba@google.com/ > > [2] https://lore.kernel.org/all/20240712232937.2861788-1-ackerleytng@google.com/ > > [3] https://lpc.events/event/18/sessions/183/#20240919 > > Fuad Tabba (10): > KVM: Introduce kvm_gmem_get_pfn_locked(), which retains the folio lock > KVM: Add restricted support for mapping guestmem by the host > KVM: Implement kvm_(read|/write)_guest_page for private memory slots > KVM: Add KVM capability to check if guest_memfd can be mapped by the > host > KVM: selftests: guest_memfd mmap() test when mapping is allowed > KVM: arm64: Skip VMA checks for slots without userspace address > KVM: arm64: Do not allow changes to private memory slots > KVM: arm64: Handle guest_memfd()-backed guest page faults > KVM: arm64: arm64 has private memory support when config is enabled > KVM: arm64: Enable private memory kconfig for arm64 > > arch/arm64/include/asm/kvm_host.h | 3 + > arch/arm64/kvm/Kconfig | 1 + > arch/arm64/kvm/mmu.c | 139 +++++++++- > include/linux/kvm_host.h | 72 +++++ > include/uapi/linux/kvm.h | 3 +- > tools/testing/selftests/kvm/Makefile | 1 + > .../testing/selftests/kvm/guest_memfd_test.c | 47 +++- > virt/kvm/Kconfig | 4 + > virt/kvm/guest_memfd.c | 129 ++++++++- > virt/kvm/kvm_main.c | 253 ++++++++++++++++-- > 10 files changed, 628 insertions(+), 24 deletions(-) > > > base-commit: 0c3836482481200ead7b416ca80c68a29cfdaabd