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 A77E3C433EF for ; Sat, 13 Nov 2021 00:00:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3302D6109D for ; Sat, 13 Nov 2021 00:00:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3302D6109D 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 67D9F6B0075; Fri, 12 Nov 2021 19:00:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 62DA66B0078; Fri, 12 Nov 2021 19:00:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CDE46B007B; Fri, 12 Nov 2021 19:00:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0254.hostedemail.com [216.40.44.254]) by kanga.kvack.org (Postfix) with ESMTP id 31B676B0075 for ; Fri, 12 Nov 2021 19:00:50 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CC37518549A93 for ; Sat, 13 Nov 2021 00:00:49 +0000 (UTC) X-FDA: 78801951018.09.1285662 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf14.hostedemail.com (Postfix) with ESMTP id A0A5B6001E7B for ; Sat, 13 Nov 2021 00:00:45 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id x7so7947651pjn.0 for ; Fri, 12 Nov 2021 16:00:44 -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=/T22u9uiXYSbjw4vUr/c0mCt/SzIILWdyE5tNdh2BGw=; b=VhQZsgvI1uZu/qRt1rBhl5uQ6ruHuXkwfFJUbOu/8oflm8Y8IjTfdrFpF5l4XDHMfw hNujv6cx9lgJ/C687c0csRkaZMgbMie5C4wI4UJn+h3SunYyBWEiUavPrYnyyBmgmypl U1v0ayQcKxxOxnWtaehUJOJ94L9U6hqLQBpJ1UKCUvsSfWv4j7QA2BzyLC2R76HJhpCp jH8Y7lsynNB8tRXk59LIf6m0nHpYJWaX7L/79Et5TybhPnccFu33hBQUB2JKrxjsWxoh hUaykcrY5mFgXt/znGHUGIqrt8hSXn/SZ318s9vC+/0BLbMS9RCdUVDk542SlhCeEoey k3xQ== 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=/T22u9uiXYSbjw4vUr/c0mCt/SzIILWdyE5tNdh2BGw=; b=2iaj2ZkmPGiuV/c3TwSlsGvL+CS/3f5ql4wqS1Ke+NOt0jKNkLWkM/fCV25AGjyq7p kf1uCga7BhjsSDGVQ6AM4M4ArKh0QaWP9f9KZ0T6D84neNkDyC67gl8qGZnqeGDJB2E3 jWRXz4xw4LYx3pYet6QQqMBLVZIH9Kxw+vHqs15+FviNLiBBHVrzyY6hkCG3i6/ki4cD P5A8tUN/9ISotCvKXZxZBVIcwZFjlHFZmUfordKpAzswUKcLVoBQ/73mSo/s+53Aio2E HkFOr5IGpnZilN3l6KJw5oOqj41KFEe36yEPiKfCprEO2JfciYilDRrMDtyieZZGzVP3 50pw== X-Gm-Message-State: AOAM532GAVBBi86jzU+MqEU/DTm935DBUebIGov+p80YMmC1YACmoP0/ JB7jcI8wKX6J78pDVmcOJNhyMw== X-Google-Smtp-Source: ABdhPJw0L5nRV7A2TEQulq2d+qnpOxthRLSY8VdwXH4zCv0Xvd9k+FIidmAI6gWHtGbettKqVbDWxQ== X-Received: by 2002:a17:90b:1bcf:: with SMTP id oa15mr41527726pjb.161.1636761643547; Fri, 12 Nov 2021 16:00:43 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id l6sm8544982pfc.126.2021.11.12.16.00.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 16:00:42 -0800 (PST) Date: Sat, 13 Nov 2021 00:00:38 +0000 From: Sean Christopherson To: Peter Gonda Cc: Borislav Petkov , Dave Hansen , Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support Message-ID: References: <20210820155918.7518-1-brijesh.singh@amd.com> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A0A5B6001E7B X-Stat-Signature: wijnwnirrgcb15aycrqq9j75jq8nh1mw Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VhQZsgvI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of seanjc@google.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=seanjc@google.com X-HE-Tag: 1636761645-310615 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, Peter Gonda wrote: > On Fri, Nov 12, 2021 at 1:55 PM Borislav Petkov wrote: > > > > On Fri, Nov 12, 2021 at 08:37:59PM +0000, Sean Christopherson wrote: > > > Let userspace decide what is mapped shared and what is mapped private. > > > > With "userspace", you mean the *host* userspace? Yep. > > > The kernel and KVM provide the APIs/infrastructure to do the actual > > > conversions in a thread-safe fashion and also to enforce the current > > > state, but userspace is the control plane. > > > > > > It would require non-trivial changes in userspace if there are multiple processes > > > accessing guest memory, e.g. Peter's networking daemon example, but it _is_ fully > > > solvable. The exit to userspace means all three components (guest, kernel, > > > and userspace) have full knowledge of what is shared and what is private. There > > > is zero ambiguity: > > > > > > - if userspace accesses guest private memory, it gets SIGSEGV or whatever. > > > > That SIGSEGV is generated by the host kernel, I presume, after it checks > > whether the memory belongs to the guest? Yep. > > > - if kernel accesses guest private memory, it does BUG/panic/oops[*] > > > > If *it* is the host kernel, then you probably shouldn't do that - > > otherwise you just killed the host kernel on which all those guests are > > running. > > I agree, it seems better to terminate the single guest with an issue. > Rather than killing the host (and therefore all guests). So I'd > suggest even in this case we do the 'convert to shared' approach or > just outright terminate the guest. > > Are there already examples in KVM of a KVM bug in servicing a VM's > request results in a BUG/panic/oops? That seems not ideal ever. Plenty of examples. kvm_spurious_fault() is the obvious one. Any NULL pointer deref will lead to a BUG, etc... And it's not just KVM, e.g. it's possible, if unlikely, for the core kernel to run into guest private memory (e.g. if the kernel botches an RMP change), and if that happens there's no guarantee that the kernel can recover. I fully agree that ideally KVM would have a better sense of self-preservation, but IMO that's an orthogonal discussion.