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 8DA2FC52D70 for ; Mon, 5 Aug 2024 18:14:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00FE66B00A4; Mon, 5 Aug 2024 14:14:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EB2FE6B00A6; Mon, 5 Aug 2024 14:14:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D05B06B00A8; Mon, 5 Aug 2024 14:14:26 -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 ABDA96B00A4 for ; Mon, 5 Aug 2024 14:14:26 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 58ABD161C04 for ; Mon, 5 Aug 2024 18:14:26 +0000 (UTC) X-FDA: 82418991732.10.6035046 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf06.hostedemail.com (Postfix) with ESMTP id 8CC18180003 for ; Mon, 5 Aug 2024 18:14:23 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=omxCOqbY; spf=pass (imf06.hostedemail.com: domain of tabba@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=tabba@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=1722881633; 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:references:dkim-signature; bh=fAeqV+sN0ITKMWm//lkdLvhATQzN1HfwEkp06Qf6xOg=; b=bFfXbsNet4c7XFSsJxwRnYCm6uHMsSqxa0ZClkKyvhiDPi4cRNKj0bgN4tROjv8hmIkPcK aPb6guxAFb10orsab5B1jj1T51Zhr2Pb2xFlCVRJ55w/eKc/T/64xp5d608BwHeJwQssNQ NMPIKTw6QEi8J/HZsITOZmMhBNivtJM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=omxCOqbY; spf=pass (imf06.hostedemail.com: domain of tabba@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722881633; a=rsa-sha256; cv=none; b=1BFT/rfp6UaOqIoxxp9I3etmoE0LItUXGqPZYG5Abj6IOAyWJ8YXThpTcSf+UfCapvUWZ9 hFEgIhwuvDkQJ18j9hUGwoxWV9Lsz9gFqG/xOnS72JT3YdE57Vop/T677GMA2qWmFUCYB0 E22IiVnBfP+WYhyrPoIEEFJa2/apgns= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-42809d6e719so75513905e9.3 for ; Mon, 05 Aug 2024 11:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722881662; x=1723486462; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fAeqV+sN0ITKMWm//lkdLvhATQzN1HfwEkp06Qf6xOg=; b=omxCOqbYSFNPI3BYwub2Pa52pVjv2SywpC36mOEAwgO+rAKltpy9DOCKWpLkFq5cy7 7qZJu6cf+9woSx2tFl4GYceiCFCFOtZpf/FgFtv+2ypTGCUuWN9zn/Vd4hRjRRsrDr/U ohoA+IuixI3fzBF1BHH/OE2e2CUbFhmeKkvTpC32m5P8550h9/E4dqexdxNxVRsbUJzu 7ns2mkOlk7+r0P+EaMv8Ye0L+jBCZ/bwnKU1LPcxqAYbIpKz9hFfO17KtKbof44R2bN8 yljbPBY3BkpkIi33uF70rDTwDd5ANN9qoMfJ1DeLEabekVDBfFWIpMjwiboidJunr3FS DRyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722881662; x=1723486462; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fAeqV+sN0ITKMWm//lkdLvhATQzN1HfwEkp06Qf6xOg=; b=kAQnQtifpGsn6s3V1RYPzAFRyPm8ruwdfunkSz5GuSfXy7ujwKC1o+pZemxbmmFFVI gKeRplsF3h+AIQjOk7Wv+pFvOTgxNPw/MdLx92jA+v/+mi6E2CcvZlHY5IvB3ffxrwJj wGGZXF4HsxGhvhEFLCMo7oQTHAfVcl8aONIZKQ8q75Vh1Qe6amRJAw+QvmytYVxCLZxV jElfIi4SIiYgcgJztyihsaUDhpzk8Omx9YwJu1z9JWwbt9sbZkNbYgwMGJcyjdTmxpxe Hvy3OrB9+V5GLcgCg2gfkRG2dyfrMbaj1+Ngr2IWSc3vE1fFVvPspNyopmwCSIoFBN61 DXow== X-Forwarded-Encrypted: i=1; AJvYcCVORAeEUH4xYBPDMD1UKYJMGnoZpKcocDh3o3+ZMmD5GVEsAf4lVl3ItG2UwGZgm+MqTIAdXqGlqGxJ5iCk8YNE33E= X-Gm-Message-State: AOJu0Yxd90uA+lw/idUyLWXgjYTsVAt4+t0Z+gm9pOQwo1W4tr2VQNc0 vNMmyulI6kuTpi4qd/X++6+fFpvstDBEs1M2tvBRcuptxfF5P2rGHmJqdyWdwEEscgC4DOYsBSW 5yazJAFSeZCEmuBFVx1UCTKA8im0sPHDq7Cs5 X-Google-Smtp-Source: AGHT+IEfhXcJinsrfbkchEG4uQywphXjLx+UXwCvHE0dt8SzKT7ubH451aLvoGt5MtLCH2b5Wn5cQvCvkgjzNhQ3bu8= X-Received: by 2002:a05:600c:1c04:b0:426:6153:5318 with SMTP id 5b1f17b1804b1-428e6b07c00mr88003955e9.19.1722881661714; Mon, 05 Aug 2024 11:14:21 -0700 (PDT) MIME-Version: 1.0 References: <20240801090117.3841080-1-tabba@google.com> In-Reply-To: From: Fuad Tabba Date: Mon, 5 Aug 2024 19:13:45 +0100 Message-ID: Subject: Re: [RFC PATCH v2 00/10] KVM: Restricted mapping of guest_memfd at the host and pKVM/arm64 support To: Ackerley Tng 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 8CC18180003 X-Stat-Signature: p45afxte3jj77s4hwqhxe4r7j8f7utip X-HE-Tag: 1722881663-441242 X-HE-Meta: U2FsdGVkX19BNWfWrU5tQ3BbdPvm+FrHIJy8LHnytwU9m9dbDNzL4XY0ZIaODpqQa+VXCnPwuetUGsF18DjQNgjjO53+wGtWciuRNgLIVnHHaR64yWgGiZie198vfjL9QOnCwc4lezRb0IQ2TAmGC0SNIloNThf30iLkl+HpkKMri72+p8qEZfGaYoNE9tVa+v82XQydaOg0RIv1/r+9JemyMk0wJa1WqfXXHOGXXQKaNvjQO43cbQHZ9yvXsC5FgOji4B+934mJWz/JooujtpVJOxVzI7LstJgL9m8AFTzGCEYVPv4hT/3YAeRQfTe/sPUA1U1JpvCZJWReHnkM3Wy6YloB/1xjQuiSXEF2zXJQLP1Jqm76w+itUrjeRudxY+CmuJmmp+CKnbVfdDr9DlM+Vi3qj7jFljuv0bJPoSS/DSmfCdPGaD18huakpuNZnLj0bpb014K13IXT9e8xTYBNo7mFdnFShQ4PqFtae+LAGr/sZ1/tjKkDAYBbUIPlnDjZgPpr2Ik21jIK4CT2x4TKDSV2gLKssZ7ciRnKLMxWjNPnCHjy9kinyv+ybRtG3aJe/tKELCu4N1EpxF1Xrnyo9v3+RFL22YE3Q0rsT6NRbRzjUzeKrgWW/P51ggOsO9r6L3/3+YoAKhUVREha53kkcox5O1KWTtJHDp+oFdrfktp+hGgZubz6H+mVt7PwPyGjhJmfs4+I1ANAc8o+NwQsiwF9UxCkMECy5r8KIGU//reNWBF1MRtQjRzDe4gurN/+JqNiM0UgE6BdYb+fA9LAmXKA8Qd0q9+bskFzoWZlzximqru0HK1G0kib9tP2kLs9hgO3PXUFfEoL6gm15UxFzlGJkwR7JJnTbGMHuL71Sj7g85OlF+Rh+M8cIdFRCtm4HoDM93lKS4EBFsBFyPImr5r4c5RJf/lRn1o9R1/1a9ighkf+yVT1SO7LNth6nu6kcGSG9O6r0vC5Eq1 6QmKMGP/ cj4a//Ft4NMhWyVDP5f+0GnHbJA/2Fsm30Ym/M8+86HhzTa8kHh52Pe4aJ8OSlVoUO6XF5aL3m978xHNtrPCeOwpziIMoZx/8WZHCvP9VDqxzDt+SKxr68y7mHqjiBpQDaVJjeS9W1va6LQuXghlj17DXbx2dTst+RjA/e1Kah+osMVD0/J1MEf/EUsL8lN2gvGgARpgC68FowQME2wfffWW3nssxfrXmYg1nyGEQDtXittNUfDQjm34K+ZQuL93XocDtwIVG+SqP9N0zwUihnztSWEF+TLRkWWiVnlSyWPaD43sHDX/VTJeyalSTKteB2w+74EHscCpDSFkXVg4gKJinfZhRIKqSKExvST9m31m9XllwAZ6i+1JL5j4jUu0Mi7ksezzCuPrijSqchqYf3MiUz7bTZmn4DKKwgBt49c57TKgr3egdwSiHE3gn3DPaX/215otc7HZCLdo= 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: Hi Ackerley, On Mon, 5 Aug 2024 at 17:53, Ackerley Tng wrote: > > 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? With mappability, I mean having a valid mapping in the host. But like I said in the reply to the other patch, I don't have a strong opinion about this. Cheers, /fuad > > 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