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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25F56C433EF for ; Sat, 13 Nov 2021 18:28:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AC982611EE for ; Sat, 13 Nov 2021 18:28:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AC982611EE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4AF0D6B0078; Sat, 13 Nov 2021 13:28:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 45D576B007B; Sat, 13 Nov 2021 13:28:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 325B86B007D; Sat, 13 Nov 2021 13:28:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 248AA6B0078 for ; Sat, 13 Nov 2021 13:28:24 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CA553181019D4 for ; Sat, 13 Nov 2021 18:28:23 +0000 (UTC) X-FDA: 78804742086.15.E9CBC07 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf17.hostedemail.com (Postfix) with ESMTP id F3B45F00038F for ; Sat, 13 Nov 2021 18:28:22 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id m14so11259997pfc.9 for ; Sat, 13 Nov 2021 10:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5Ycmt8tegHM9+iX2tw5kVKKQzYyX28cv7Zc0okImoEE=; b=S0fC6nUpGsYzMDkH2fwRs2kslWGsA0ZT433CI4HTX9RKW5R96rXkcQ/0Zyd00TxgsA 3JKbKipk4vpz56yCcFNbQIuQqjsCczhrMCYx00uSOjXMxpUjSj60DkNqZl/Yb225PSb1 ShrqJF6fxpJ5JQxJQ9HImAZL1hsIkrWX/d0+TBsWu80+W91/3jdRmWD8pieJYmU5r9jr uAvF4Qcy0159z4xAvQagHfO2T4J4m+CDLVYDN+KmSL7qR6s06QYrglpM4qsrqLdlkY2M GkaQeb87LHzjh3U0dSuftpxx1AU4Vhurn/wCS3UhRblDyYA0/UZuZzO8jmOr4uRfUC7P iLOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5Ycmt8tegHM9+iX2tw5kVKKQzYyX28cv7Zc0okImoEE=; b=bRkEqWNvxID4gmWu5v/Ecz1iaC46W5ql049s3pz+5dYXpCx4E50pyvjx8d6dMCuH73 odielcjGLUtq1Yr2XSIq9wiA9G7Lo4XtoGRjYEmEcD8DM2Q4owucMXP31f7B4CooSQKA kmC289YHlLqFYFqI47HMDIdGG0Xj9zTCy5rmpLRgEQR7Bh4NlmpxheSu/2qiUu1Rthhp A8peZ7OZCDe/ehhGYFnvu2qqS2br+QNSxsoDHepLZhojwQsaVPru+BEQALw3+h83DDdk OwnWVKo3QtNd0NWQOQ3X3p4QRa2XlpklwYu6hzuEF0THQpz2pk0ltDLDdtAMdwVlj0Yd xgdA== X-Gm-Message-State: AOAM532J+4FmzhPDK1y3BxkYZkGi4ZUZ12q0wksdOlCiNIi/K5JWRcTf weGTJoLA8o2kufT12nurTgNNAw== X-Google-Smtp-Source: ABdhPJwd0lZ9M5eG7/pjsaMsb0UCHSKrCM/hqTbMkiLkRbr2swjCDNY5Edw8/HsS2qWXhggajuV/kw== X-Received: by 2002:a62:1b86:0:b0:47b:d112:96d4 with SMTP id b128-20020a621b86000000b0047bd11296d4mr22281236pfb.52.1636828101667; Sat, 13 Nov 2021 10:28:21 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id z13sm10074099pfg.36.2021.11.13.10.28.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 10:28:20 -0800 (PST) Date: Sat, 13 Nov 2021 18:28:16 +0000 From: Sean Christopherson To: Marc Orr Cc: Peter Gonda , Andy Lutomirski , Borislav Petkov , Dave Hansen , Brijesh Singh , the arch/x86 maintainers , Linux Kernel Mailing List , kvm list , linux-coco@lists.linux.dev, linux-mm@kvack.org, Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Dave Hansen , Sergio Lopez , "Peter Zijlstra (Intel)" , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Sathyanarayanan Kuppuswamy Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Message-ID: References: <2cb3217b-8af5-4349-b59f-ca4a3703a01a@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: F3B45F00038F X-Stat-Signature: uu66chm53udyc5q7jnjsebwrz1hyp5i7 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=S0fC6nUp; spf=pass (imf17.hostedemail.com: domain of seanjc@google.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1636828102-424458 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 Fri, Nov 12, 2021, Marc Orr wrote: > On Fri, Nov 12, 2021 at 4:53 PM Sean Christopherson wrote: > > On Fri, Nov 12, 2021, Peter Gonda wrote: > > > Having a way for userspace to lock pages as shared was an idea I just > > > proposed the simplest solution to start the conversation. > > > > Assuming you meant that to read: > > > > Having a way for userspace to lock pages as shared is an alternative idea; I > > just proposed the simplest solution to start the conversation. > > > > The unmapping[*] guest private memory proposal is essentially that, a way for userspace > > to "lock" the state of a page by requiring all conversions to be initiated by userspace > > and by providing APIs to associate a pfn 1:1 with a KVM instance, i.e. lock a pfn to > > a guest. > > > > Andy's DMA example brings up a very good point though. If the shared and private > > variants of a given GPA are _not_ required to point at a single PFN, which is the > > case in the current unmapping proposal, userspace doesn't need to do any additional > > juggling to track guest conversions across multiple processes. > > > > Any process that's accessing guest (shared!) memory simply does its locking as normal, > > which as Andy pointed out, is needed for correctness today. If the guest requests a > > conversion from shared=>private without first ensuring the gfn is unused (by a host > > "device"), the host will side will continue accessing the old, shared memory, which it > > locked, while the guest will be doing who knows what. And if the guest provides a GPA > > that isn't mapped shared in the VMM's address space, it's conceptually no different > > than if the guest provided a completely bogus GPA, which again needs to be handled today. > > > > In other words, if done properly, differentiating private from shared shouldn't be a > > heavy lift for host userspace. > > > > [*] Actually unmapping memory may not be strictly necessary for SNP because a > > #PF(RMP) is likely just as good as a #PF(!PRESENT) when both are treated as > > fatal, but the rest of the proposal that allows KVM to understand the stage > > of a page and exit to userspace accordingly applies. > > Thanks for this explanation. When you write "while the guest will be > doing who knows what": > > Isn't that a large weakness of this proposal? To me, it seems better > for debuggability to corrupt the private memory (i.e., convert the > page to shared) so the guest can detect the issue via a PVALIDATE > failure. The behavior is no different than it is today for regular VMs. > The main issue I see with corrupting the guest memory is that we may > not know whether the host is at fault or the guest. Yes, one issue is that bugs in the host will result in downstream errors in the guest, as opposed to immediate, synchronous detection in the guest. IMO that is a significant flaw. Another issue is that the host kernel, which despite being "untrusted", absolutely should be acting in the best interests of the guest. Allowing userspace to inject #VC, e.g. to attempt to attack the guest by triggering a spurious PVALIDATE, means the kernel is failing miserably on that front.