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 8FEE5C433F5 for ; Mon, 15 Nov 2021 18:17:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3275063409 for ; Mon, 15 Nov 2021 18:17:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3275063409 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 7C7B96B0078; Mon, 15 Nov 2021 13:17:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 750066B007B; Mon, 15 Nov 2021 13:17:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A3036B007E; Mon, 15 Nov 2021 13:17:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 441B86B0078 for ; Mon, 15 Nov 2021 13:17:58 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C9A1184D1E for ; Mon, 15 Nov 2021 18:17:57 +0000 (UTC) X-FDA: 78811973394.24.ABDC616 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 91B1E5092D25 for ; Mon, 15 Nov 2021 18:17:32 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id u17so15124241plg.9 for ; Mon, 15 Nov 2021 10:17:57 -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=zVIigt5hFRhwoHdnPkqdezNkgtT3bQVD+JV1TZ0yBQk=; b=aIFb+Bg2kAQ6u2avnkXgX+2F+XsjwU8PJbAILzNG66y0Npi9zFLasu3DiaXqW2vnUq XQn2eLnu4wHnrtJsF/JKd/GXTb/hXXs1b1tvMaulKoZJJG/RKlWLZNxsr6DJPAMgyhyQ gLSA7I+KjaST0YMZnMn+HI9FW40+/+MwqE+2nhY8Y+6N2j7cMXMxniw6Tf0yVSTkiE3U w1EBeHcm/riM8DRmyCdwozujjMclAB0IhtYBKO4J4uioDIWabX2Ng1GO2HH+mbCJlpC9 38U5GlMY9tw62ZR1mlT3p0jLcsVoNuP7Qbvh/lSUuU7SQnhyzDLppN9qLlWFSqBZZGwk +MGA== 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=zVIigt5hFRhwoHdnPkqdezNkgtT3bQVD+JV1TZ0yBQk=; b=rjWh4O/H1JlOO5WeAqeJRoso84n61AAPwMF/1SfLEu0ynzNvsl/IgyrkBjVajTX+Sn 2saQYre0ZK9mAMGQ/Jnpi+av1DXeJF8ZS87cDl64ej9PwfZjEeZwB/4GtBpOeuaSjuEX UEdfEIxsjss/CNlGq2H7WUII3DV3641a/0piHrJgG8vWUAuceOC5rQoEOwxMkeJ3HJgc zq2JJx8MGHhtqJ/lxX/vjJh2Mu+PLuKx1Z557UPNz04mH6G7Lq7KsfiGMWg1vrftWlD4 tDnT8cTtocEHFAHz3ZoaBsgwzcMGYuLcrCCeeRnhfjjJpQ5B6afTFE2Rmg9vXts76Cfl gKUw== X-Gm-Message-State: AOAM532Y+3wcnkI8oGu+Gz/zQ3VMO65CpHS5FNvLcvhmiyVVGrG9N0sv sOlGU0bnJ5YTxazbUuHnVHlpeQ== X-Google-Smtp-Source: ABdhPJyEk01A4cEBJRk2IJwMDA9ufuQA+Un9JScTgr2yhZJMzSPbmQlcRKUkuJ1yVS564FPMQwEnDg== X-Received: by 2002:a17:90b:4b04:: with SMTP id lx4mr647925pjb.11.1637000276010; Mon, 15 Nov 2021 10:17:56 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id c3sm11160202pgk.16.2021.11.15.10.17.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Nov 2021 10:17:55 -0800 (PST) Date: Mon, 15 Nov 2021 18:17:51 +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: 91B1E5092D25 X-Stat-Signature: oxr1kt9dckikdduzuh14ih6aagyki791 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=aIFb+Bg2; spf=pass (imf05.hostedemail.com: domain of seanjc@google.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1637000252-597663 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 Sat, Nov 13, 2021, Marc Orr wrote: > On Sat, Nov 13, 2021 at 10:28 AM Sean Christopherson wrote: > > The behavior is no different than it is today for regular VMs. > > Isn't this counter to the sketch you laid out earlier where you wrote: > > --- QUOTE START --- > - if userspace accesses guest private memory, it gets SIGSEGV or whatever. > - if kernel accesses guest private memory, it does BUG/panic/oops[*] > - if guest accesses memory with the incorrect C/SHARED-bit, it gets killed. > --- QUOTE END --- > > Here, the guest does not get killed. Which seems hard to debug. No, it does contradict that statement. 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. In this case, the guest will have converted a GPA from shared=>private, i.e. changed the effective GFN for a e.g. a shared queue, without informing host userspace that the GFN, and thus the associated HVA in the host, has changed. For TDX that is literally the same bug as the guest changing the GFN without informing the host, as the SHARED bit is just an address bit with some extra meaning piled on top. For SNP, it's slightly different because the C-bit isn't strictly required to be an address bit, but for all intents and purposes it's the same type of bug. I phrased it "guest will be doing who knows what" because from a host userspace perspective, it can't know what the guest behavior will be, and more importantly, it doesn't care because (a) the guest is buggy and (b) the host itself is _not_ in danger. Yes, those types of bugs suck to debug. But they really should be few and far between. The only reason I called out this specific scenario was to note that host userspace doesn't need to take extra steps to guard against bogus shared=>private conversions, because host userspace already needs to have such guards in place. In prior (offline?) conversations, we had assumed that host userspace would need to propagate the shared vs. private status to any and all processes that map guest memory, i.e. would require substantial enabling, but that assumption was wrong. > If allowing userspace to inject #VC into the guest means that the host > can continue to serve other guests, that seems like a win. The > alternative, to blow up the host, essentially expands the blast radius > from a single guest to all guests. As mentioned in other threads of this conversation, when I say "host crashes", I am specifically talking about scenarios where it is simply not possible for the host kernel to recover, e.g. an RMP #PF violation on the IDT. Setting that aside, injecting a #VC into the guest is not in anyway necessary for a buggy host userspace to terminate a single guest, host userspace can simply stop running that specific guest.