From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E359E6FAA for ; Mon, 21 Aug 2023 14:42:30 +0000 (UTC) Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-1bf681d3d04so17820395ad.2 for ; Mon, 21 Aug 2023 07:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1692628950; x=1693233750; 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=AR0RjJtQ4jbaps5Qss/ICM2Xr4u5GSwen1y9lR5GJNU=; b=yZr9ifC1oJ3851c1QEBzwLDnbBmO/fLPz7OlYonWjqUikL6hAqH8u/LYwSD8ZKe6pD EqW2f1iAfsM+S4YDbQ9SnVzllVZLQhKAwMHHph9phX7p9FxSMETiOnNdDqTttvwruvd+ 6yydgITA/Xe6R8jV1gRLSidEuc5nqM6H3MOYNFqdPfxphcj9YF7ChMAUPgx49PFbv6yR I7WiVPfWxOUqFe+5oFocn0+nzPizZJzG0qoLaPo8JkphHjX4+g6bO3H9asXIt33o3ils 1bvtaZVn7TViaPiJzMUBiS1JqPHWKejWT6CqSwVD3ah/WIKy5nZhnzS26Fvo6BqFNPvP Pocg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692628950; x=1693233750; 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=AR0RjJtQ4jbaps5Qss/ICM2Xr4u5GSwen1y9lR5GJNU=; b=fpzSyTZjXq6cymHbxayfax4IbnAgssIfsEm3cVzi7lD2AtVZtaIeJqy2upZBL2rbkD hX+ZKjcIT729X1xulQ+7lE6wsR82VZgK8DP2Qmj5SmyZ3XxaoxeHDqFYKAY9W3Ea3IaO 3sMsQiVm2XNpB79n0ZKBXH6VVs9GvpIIKf0P3zPhLeoaLWnxWQyQNBaFyH7NhwKWxH2w /tQ1P3yBiM8mpZXWhE1QBuB3fbFBtceaehrIOP/suJbpFwqBlpKungCm+5QXkaKQtjDI OuGpaOLviSVlMQI8VmGBHFRQNeO4nRstwYt7Z2i+p49s1qgWaO/j02yG+6qkcxOYQiWi Op/Q== X-Gm-Message-State: AOJu0Yzu2h6bfqFwRzVGo3mgU9p7rEfWrATlN7pf4E4ihz00kh0zoExK 2foys8eANTnII09fyiWVyRX0ndaNsEU= X-Google-Smtp-Source: AGHT+IEC+qozyNRvIPltiH3ul3i5rVi4vVuDAyC4VloCOa7LYkPDbctBI//9ISW5qNkoZ/M1zYnU/8iOFg0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:dace:b0:1bb:91c9:d334 with SMTP id q14-20020a170902dace00b001bb91c9d334mr3111000plx.0.1692628950096; Mon, 21 Aug 2023 07:42:30 -0700 (PDT) Date: Mon, 21 Aug 2023 07:42:28 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <52c6a8a6-3a0a-83ba-173d-0833e16b64fd@amd.com> Message-ID: Subject: Re: [PATCH 4/8] KVM: gmem: protect kvm_mmu_invalidate_end() From: Sean Christopherson To: Mingwei Zhang Cc: Jacky Li , Ashish Kalra , isaku.yamahata@intel.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com, Michael Roth , Paolo Bonzini , erdemaktas@google.com, Sagi Shahar , David Matlack , Kai Huang , Zhi Wang , chen.bo@intel.com, linux-coco@lists.linux.dev, Chao Peng , Ackerley Tng , Vishal Annapurve , Yuan Yao , Jarkko Sakkinen , Xu Yilun , Quentin Perret , wei.w.wang@intel.com, Fuad Tabba Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 18, 2023, Mingwei Zhang wrote: > +Jacky Li >=20 > On Fri, Aug 18, 2023 at 3:45=E2=80=AFPM Sean Christopherson wrote: > > > On a separate note here, the SEV hook blasting WBINVD is still causin= g > > > serious performance degradation issues with SNP triggered via > > > AutoNUMA/numad/KSM, etc. With reference to previous discussions relat= ed to > > > it, we have plans to replace WBINVD with CLFLUSHOPT. > > > > Isn't the flush unnecessary when freeing shared memory? My recollectio= n is that > > the problematic scenario is when encrypted memory is freed back to the = host, > > because KVM already flushes when potentially encrypted mapping memory i= nto the > > guest. > > > > With SNP+guest_memfd, private/encrypted memory should be unreachabled v= ia the > > hva-based mmu_notifiers. gmem should have full control of the page lif= ecycles, > > i.e. can get the kernel virtual address as appropriated, and so it SNP = shouldn't > > need the nuclear option. > > > > E.g. something like this? > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > index 07756b7348ae..1c6828ae391d 100644 > > --- a/arch/x86/kvm/svm/sev.c > > +++ b/arch/x86/kvm/svm/sev.c > > @@ -2328,7 +2328,7 @@ static void sev_flush_encrypted_page(struct kvm_v= cpu *vcpu, void *va) > > > > void sev_guest_memory_reclaimed(struct kvm *kvm) > > { > > - if (!sev_guest(kvm)) > > + if (!sev_guest(kvm) || sev_snp_guest(kvm)) > > return; > > > > wbinvd_on_all_cpus(); >=20 > I hope this is the final solution :) >=20 > So, short answer: no. >=20 > SNP+guest_memfd prevent untrusted host user space from directly > modifying the data, this is good enough for CVE-2022-0171, but there > is no such guarantee that the host kernel in some scenarios could > access the data and generate dirty caches. In fact, AFAIC, SNP VM does > not track whether each page is previously shared, isn't it? If a page > was previously shared and was written by the host kernel or devices > before it was changed to private. No one tracks it and dirty caches > are there! There's an unstated assumption that KVM will do CLFLUSHOPT (if necessary) f= or SEV-* guests when allocating into guest_memfd(). > So, to avoid any corner case situations like the above, it seems > currently we have to retain the property: flushing the cache when the > guest memory mapping leaves KVM NPT. What I'm saying is that for guests whose private memory is backed by guest_= memfd(), which is all SNP guests, it should be impossible for memory that is reachab= le via mmu_notifiers to be mapped in KVM's MMU as private. So yes, KVM needs to f= lush when memory is freed from guest_memfd(), but not for memory that is reclaim= ed by mmu_notifiers, i.e. not for sev_guest_memory_reclaimed().