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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE9FEC433B4 for ; Mon, 19 Apr 2021 18:09:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 42A6B60FE8 for ; Mon, 19 Apr 2021 18:09:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42A6B60FE8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9D3B26B0036; Mon, 19 Apr 2021 14:09:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95B216B006E; Mon, 19 Apr 2021 14:09:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7ADD06B0070; Mon, 19 Apr 2021 14:09:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 594866B0036 for ; Mon, 19 Apr 2021 14:09:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0C7742484 for ; Mon, 19 Apr 2021 18:09:36 +0000 (UTC) X-FDA: 78049904352.06.0F87CE8 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) by imf23.hostedemail.com (Postfix) with ESMTP id D080BA000381 for ; Mon, 19 Apr 2021 18:09:33 +0000 (UTC) Received: by mail-pg1-f169.google.com with SMTP id p12so24818218pgj.10 for ; Mon, 19 Apr 2021 11:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=JUnfh0pPTrADDE5ELA+4XLvS6WL0YCiwkGF+Ud8ird8=; b=gVSJkZhYfwM6kw+ptrMrrBqiowP0QK/MTQrX80iGcTyqt0Nui8BfDhHTZfkAKzObwu ZeFuyE4ol8P5d++A0LiroAJ6mp+xlu8ICWB2rkgZoaa4qE429e+7Vtsj2fK3naZebWpJ NK4tdLZs4JwFPzTsYaIvfHzqgn8ujWJrhXXQDc+YCvgxrjUvVkGt2bHRzrIZ/uEmDRzB oILq+PtO7IdOMY9865se4DdwVTSKOjYXZUzrcAHB1ZTo85rJMsIkGjtutPBNkkdlxo3I 1J6w0E4Tih1MEpMU3r08b6+M3T8s/jK6ynpmm1idIAIZQkxzLnvVQHKnSeDpGbBLE0dd LSrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=JUnfh0pPTrADDE5ELA+4XLvS6WL0YCiwkGF+Ud8ird8=; b=Ja83x5KNKUrQAKXMdTnzhsfWaLJxrfrkQkr2IKs82J+rXM/S7cQmsDMARrAgCUsSOO oTUADk77jXrjoqeGX4BLcnYyE4L+//gsmxii9nVJ6OAqigm2sfB99IFcUd6333RXiU2C dUty/V4IRg7TIojtflWUu/B/Vhrf2/RNPLR619L6my2qdzLkJG+sDeSJnzJ+mm2vkZHx 4hD/2TS4TwKw9DHtsiXog1a1cCAediyhJ/B4WUeFtGID+bSFsx9GQ0i3xZpmJaFAAf0C GCnHegeYX3fyO7z5c4xRZjs8a6mYFeoViT87YKreYu5SKDWY5cRg+9hQuV8yhfeGTBXV YRBQ== X-Gm-Message-State: AOAM532132KGIIfTmqsq8Ks9Wp1VGzE9Rs4dxRt99craoN/72NRAN5yz kj07Ok1pwVAzVFAvbwaUBk7/sg== X-Google-Smtp-Source: ABdhPJx2AIFxFdpQljQJ12l5gqvXUH3In64e71gFGnOtU1ZW8Q5a+YB0Qhi9EgSdz37xacvEnTRocA== X-Received: by 2002:a62:d108:0:b029:25d:497e:2dfd with SMTP id z8-20020a62d1080000b029025d497e2dfdmr10132772pfg.29.1618855774343; Mon, 19 Apr 2021 11:09:34 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id 63sm5957168pfx.202.2021.04.19.11.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Apr 2021 11:09:33 -0700 (PDT) Date: Mon, 19 Apr 2021 18:09:29 +0000 From: Sean Christopherson To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Jim Mattson , David Rientjes , "Edgecombe, Rick P" , "Kleen, Andi" , "Yamahata, Isaku" , Erdem Aktas , Steve Rutherford , Peter Gonda , David Hildenbrand , x86@kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 13/13] KVM: unmap guest memory using poisoned pages Message-ID: References: <20210416154106.23721-1-kirill.shutemov@linux.intel.com> <20210416154106.23721-14-kirill.shutemov@linux.intel.com> <20210419142602.khjbzktk5tk5l6lk@box.shutemov.name> <20210419164027.dqiptkebhdt5cfmy@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210419164027.dqiptkebhdt5cfmy@box.shutemov.name> X-Rspamd-Queue-Id: D080BA000381 X-Stat-Signature: zjxnbkns1oizd1kwiy9bsh8e1mayb7qk X-Rspamd-Server: rspam02 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf23; identity=mailfrom; envelope-from=""; helo=mail-pg1-f169.google.com; client-ip=209.85.215.169 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618855773-262383 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: On Mon, Apr 19, 2021, Kirill A. Shutemov wrote: > On Mon, Apr 19, 2021 at 04:01:46PM +0000, Sean Christopherson wrote: > > But fundamentally the private pages, are well, private. They can't be shared > > across processes, so I think we could (should?) require the VMA to always be > > MAP_PRIVATE. Does that buy us enough to rely on the VMA alone? I.e. is that > > enough to prevent userspace and unaware kernel code from acquiring a reference > > to the underlying page? > > Shared pages should be fine too (you folks wanted tmpfs support). Is that a conflict though? If the private->shared conversion request is kicked out to userspace, then userspace can re-mmap() the files as MAP_SHARED, no? Allowing MAP_SHARED for guest private memory feels wrong. The data can't be shared, and dirty data can't be written back to the file. > The poisoned pages must be useless outside of the process with the blessed > struct kvm. See kvm_pfn_map in the patch. The big requirement for kernel TDX support is that the pages are useless in the host. Regarding the guest, for TDX, the TDX Module guarantees that at most a single KVM guest can have access to a page at any given time. I believe the RMP provides the same guarantees for SEV-SNP. SEV/SEV-ES could still end up with corruption if multiple guests map the same private page, but that's obviously not the end of the world since it's the status quo today. Living with that shortcoming might be a worthy tradeoff if punting mutual exclusion between guests to firmware/hardware allows us to simplify the kernel implementation. > > > - Add a new GUP flag to retrive such pages from the userspace mapping. > > > Used only for private mapping population. > > > > > - Shared gfn ranges managed by userspace, based on hypercalls from the > > > guest. > > > > > > - Shared mappings get populated via normal VMA. Any poisoned pages here > > > would lead to SIGBUS. > > > > > > So far it looks pretty straight-forward. > > > > > > The only thing that I don't understand is at way point the page gets tied > > > to the KVM instance. Currently we do it just before populating shadow > > > entries, but it would not work with the new scheme: as we poison pages > > > on fault it they may never get inserted into shadow entries. That's not > > > good as we rely on the info to unpoison page on free. > > > > Can you elaborate on what you mean by "unpoison"? If the page is never actually > > mapped into the guest, then its poisoned status is nothing more than a software > > flag, i.e. nothing extra needs to be done on free. > > Normally, poisoned flag preserved for freed pages as it usually indicate > hardware issue. In this case we need return page to the normal circulation. > So we need a way to differentiate two kinds of page poison. Current patch > does this by adding page's pfn to kvm_pfn_map. But this will not work if > we uncouple poisoning and adding to shadow PTE. Why use PG_hwpoison then?