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 5F65CC001B0 for ; Fri, 11 Aug 2023 17:44:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0F3A6B0075; Fri, 11 Aug 2023 13:44:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBF746B0078; Fri, 11 Aug 2023 13:44:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A606D6B007B; Fri, 11 Aug 2023 13:44:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 92AAF6B0075 for ; Fri, 11 Aug 2023 13:44:16 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6DB4A16093E for ; Fri, 11 Aug 2023 17:44:16 +0000 (UTC) X-FDA: 81112547712.09.D43FC2E Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf03.hostedemail.com (Postfix) with ESMTP id 7878A20013 for ; Fri, 11 Aug 2023 17:44:14 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=z4avZMYB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of 3bXPWZAYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3bXPWZAYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691775854; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=y5tf/etP9591sBoXXP0u0lhmE2sGhQYCIj4rXej+PgY=; b=2h4YcCUYgQewTO96xXslyRYJLBlKWcwhXrFmAmgh3C5Ete4OjztWTjNVCMCb3YqA/xs3jn IaKyfh0u6TLhhc7ie0eVcngbr6+DqD80N+T6hJZAaRGpxrDLTPk8ICI4u39rK4F3u8l04u oNjsoP+ca3aM8L+9u4E5R+KE+i3PmoU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=z4avZMYB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of 3bXPWZAYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3bXPWZAYKCNoOA6JF8CKKCHA.8KIHEJQT-IIGR68G.KNC@flex--seanjc.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691775854; a=rsa-sha256; cv=none; b=X5wOX2pi5QV3J42MArYmxp7B7+QP8OZqqy6hcy4kAyQdaQC9wMYsKgtH0e4IB9PyO3g7n4 bShlpvJRnChsEbK9352cT+tVGJi+YNtDTX5g4vjS+XWuoHRF5Hw18yxeV4Wqt3qf7hnKYC r3awe5L6MNifcjGEObki9ol3BkU2ckI= Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-d672f55d48dso744350276.2 for ; Fri, 11 Aug 2023 10:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691775853; x=1692380653; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=y5tf/etP9591sBoXXP0u0lhmE2sGhQYCIj4rXej+PgY=; b=z4avZMYBxF/USDP2G14KA+P8N8yreov1u2JOHwfc1TVZdl6Iz+YTKH19wDx7mUMq9M o4u6qon1QiMk8DVxh93qeN2Mz6fZGsUFtzOg33bB4Mo7KFsOypRjJRdzz9Y8WFCiY85q br+fPgBO/on1YU5soxnymBtm9OPZyICHaFKZfYSg9Ropko2mo0wKLVwIok1lVrWFw51i jjhtl/HK+nEz+jNhJe7imTF+VBA6+NGFZjFm7+hHqXCkfP3+rYY1oaYSypJ0v6009kFT lq7bEwknPOhWjDhET6YMFrJ/3n1YTZ5hf1bP/IHZB/5/XDyHPzuDGnqfF1kEhe1cc6AD 1nfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691775853; x=1692380653; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=y5tf/etP9591sBoXXP0u0lhmE2sGhQYCIj4rXej+PgY=; b=Wm/Y7v0qe2UX/XlJ31MYvelrOxPIFB+4gO/tcKp7B6J221VypAE4NkXyaRQ0PCS1qk AV5vRZkmMc2zffVptgZJYA6rEzNjkgIR3ALiTzLAOOPFITB/u8cfBsFxVW3GiRNkcLPK DCiavAFFUy8WnbzehboXwZ9JaclXe2anB+iMvP5KlzAO0m2/azdcXjOXkWkqcEpwVUD5 G5j78O4sAcXRIFv8oD//rOTYoi9YH43kUCkqSX4H7lkPbgYrbyRB/qql619QLXPPu8XP jbC+aB6iGdT0h5NZVZbckG7zhRow7D5MTiyxj3B8Y0L8hONhVxvqmfrQ9UwHvwTUsbeg neAg== X-Gm-Message-State: AOJu0YyrVOT9tozVIu9UXCvIBgg2vflhbWuay5WYcyOzn0XWi6ucdoEW Wt1fr7dEk14DDD5sd2Zsc4J6iKd+s5w= X-Google-Smtp-Source: AGHT+IFlh+eXwF8rMcD2luIRCX1nl8Idt0F+6stO6hsWWfidj415wHUgqoJc8kVAwNGB8y2mQW1tGjk2lPA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:7443:0:b0:d20:7752:e384 with SMTP id p64-20020a257443000000b00d207752e384mr41859ybc.3.1691775853469; Fri, 11 Aug 2023 10:44:13 -0700 (PDT) Date: Fri, 11 Aug 2023 10:44:11 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230718234512.1690985-13-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory From: Sean Christopherson To: Vishal Annapurve Cc: Ackerley Tng , pbonzini@redhat.com, maz@kernel.org, oliver.upton@linux.dev, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, willy@infradead.org, akpm@linux-foundation.org, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, chao.p.peng@linux.intel.com, tabba@google.com, jarkko@kernel.org, yu.c.zhang@linux.intel.com, mail@maciej.szmigiero.name, vbabka@suse.cz, david@redhat.com, qperret@google.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7878A20013 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: dk1oq4mwjrtb4s9c1bpdmcou5xqdhegh X-HE-Tag: 1691775854-914937 X-HE-Meta: U2FsdGVkX1/Ww+hwgdQSEgfw34rqbBDVvIyF/Ohex0ul4weFZhBWAz4yReT6FdtC2siWtC5GvkqS4qOupy0ft+eEWWzJT8NqYUn0ZFzPKZflIgZ33oP6ibC8+nhrAt+9LpQkNsja+WrrlySH3QIKBh4xuJ7lsklCi/kC7c7r7rhHEsl6Two68VcRDKhKOHzKsjqsMhem4Ci4lzcdMcxJ47jKPkRUwpCfbSG8i5kxGtCLbD0+HGEu4vVoQciwHnxQPAfgHyG9rYdddB3pSBZyLk28BEEteMW+/FPiQlbQPzyvkqEuyWC/09UVCoE3btxkEoLkGXPiOzeNqNTckZnV+jGyDtbZ8wJPg+YWcgjGSNrCogKrvyrg1eOx79Ut0I4MxksnWbIbzcratG9FrxG0gZFYALRKl7szgsU4tTSb9LxyjuzW3KlHRuXuAiyNG8vB+SncPjTbqLzpaUT8JeYICG+6z0dazcZTsc9zjdxzgfRTNMOC6rFvHNrvcblCkGTzBu+0ueMAH4aLPBZId1rlc8vp225yseX57FyWeEYRbm86uLHYw/c8ck+WBekCWWEQF7g09+qacJALeAOFYsL5Oymtcs4w9UwM0Aw5N63gOThcfVroODueVAZntTHtEKNcy4g+q4qDL9ku10ycban4YYB4Gqx4Nkh5hjLmp9GAy5qgZTL9rh0jdS2JRwJCTFk0pE5m7fXtlZJoqKIDRhhywwrrwDgdqoIRrghiopaMTi+X3wl1EMWCFlIP2hqHONU1Np4g4HmuHQlLSbeaRD+tVrizKQjTzH1vbGKY25rtxL6gKGKLUrrLLP8gWAQGIiFFDdJn2DYNunVe60iDeGxxelFwBUquBkMoKWL1UDI1C67ZAQS6bwUTui8Yhchy3UPdlQXCYkAZEgqP0GUEsinnATepeun5BYaDQDPRUL2O3aRxxLij7+6maatQbRZTGM9Tf7bJbw6D4FPIZ3Iggd2 1D6dlCVG LPsxWE1xlJQ7wy7vJKSgYDOAX6BINvD0uTIebYpjGn12+E3RzRg2Sl+q4zSX6RFnUoglm0G1hZaoDMi+umNMAlo9ZhNRmsmQkYDbjS4E4Mu493Gv4hE2tXjF3K+jxram5UOxYTs+lUUgGHsjW/LuabUEResHaeRRoFO045VERZeix7RdhhLa+EbEe3DqocmCnNJ4n6aik6hmxasEoBi8zko2S2k5eVW1NyZlDEYWXcyH2V0mMeP29HqZ4LsHI5+5Df6Uhn0PwqF+/jXeH6bynW6hXHThKw4QiOaDCVAAFgXHRcaUpONf5wsvWWtZqYDNLhQXvyOdK6tD/pX4zwX7/qcMdFuuaPbYYWY1rx2uvQAWfbdOpnVof/cc9gPuNLuZsWMr0OtAtw/oK0PnYaFovI9IG4ml5Ca0hAdC4ZKywqajGIjpKWeYgxj8IjqrBlXKIBDW7VCzsM777h5PG4uAg/RhgkI22z00vXfzkQy9q7jhJxDHjC1qVKw/TLn7hP3NNZZ/a3b2EY7qTqFYUwJkwm+6qMpuxXapBLWHWc9QebxoEWNdAJipZUo+oKdhPOPL4MSo0I8p1YN24efukQKZu/1bQqAtzl/P64e2ioLnJxW+7/A40LK95JsY8rAFjKA5aY96F6Z9wuU/sXH7jIPLLeqtEsY5bW01esZB81vwMyh/DgjXOWUxqTQZ3Xmm+ixAID3FnmPIq7vng6PGgJO0/FHP08md0mjbnuJZAgLTfg+8hxBokhChsNgX8GSBJ5asL8EQwmr4TLDcjL2o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000193, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Aug 10, 2023, Vishal Annapurve wrote: > On Tue, Aug 8, 2023 at 2:13=E2=80=AFPM Sean Christopherson wrote: > > ... >=20 > > > + When binding a memslot to the file, if a kvm pointer exists, it mus= t > > > be the same kvm as the one in this binding > > > + When the binding to the last memslot is removed from a file, NULL t= he > > > kvm pointer. > > > > Nullifying the KVM pointer isn't sufficient, because without additional= actions > > userspace could extract data from a VM by deleting its memslots and the= n binding > > the guest_memfd to an attacker controlled VM. Or more likely with TDX = and SNP, > > induce badness by coercing KVM into mapping memory into a guest with th= e wrong > > ASID/HKID. > > >=20 > TDX/SNP have mechanisms i.e. PAMT/RMP tables to ensure that the same > memory is not assigned to two different VMs. One of the main reasons we pivoted away from using a flag in "struct page" = to indicate that a page was private was so that KVM could enforce 1:1 VM:page = ownership *without* relying on hardware. And FWIW, the PAMT provides no protection in this specific case because KVM= does TDH.MEM.PAGE.REMOVE when zapping S-EPT entries, and that marks the page cle= ar in the PAMT. The danger there is that physical memory is still encrypted with= the guest's HKID, and so mapping the memory into a different VM, which might no= t be a TDX guest!, could lead to corruption and/or poison #MCs. The HKID issues wouldn't be a problem if v15 is merged as-is, because zappi= ng S-EPT entries also fully purges and reclaims the page, but as we discussed = in one of the many threads, reclaiming physical memory should be tied to the i= node, i.e. to memory truly being freed, and not to S-EPTs being zapped. And ther= e is a very good reason for wanting to do that, as it allows KVM to do the expen= sive cache flush + clear outside of mmu_lock. > Deleting memslots should also clear out the contents of the memory as the= EPT > tables will be zapped in the process No, deleting a memslot should not clear memory. As I said in my previous r= esponse, the fact that zapping S-EPT entries is destructive is a limitiation of TDX,= not a feature we want to apply to other VM types. And that's not even a fundamen= tal property of TDX, e.g. TDX could remove the limitation, at the cost of consu= ming quite a bit more memory, by tracking the exact owner by HKID in the PAMT an= d decoupling S-EPT entries from page ownership. Or in theory, KVM could workaround the limitation by only doing TDH.MEM.RAN= GE.BLOCK when zapping S-EPTs. Hmm, that might actually be worth looking at. > and the host will reclaim the memory. There are no guarantees that the host will reclaim the memory. E.g. QEMU w= ill delete and re-create memslots for "regular" VMs when emulating option ROMs.= Even if that use case is nonsensical for confidential VMs (and it probably is no= nsensical), I don't want to define KVM's ABI based on what we *think* userspace will do= .