From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (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 5F3B02C85 for ; Sat, 13 Nov 2021 00:10:31 +0000 (UTC) Received: by mail-oi1-f176.google.com with SMTP id o4so20861020oia.10 for ; Fri, 12 Nov 2021 16:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKWR0Y85NN7RyQ3kGVx0D7iJn85BJCX0K42JtUXarAU=; b=JYfrhOhYB5iowTwOaEQsAuvCl/7R6EpEwANtkrLj6rABd0tsys3aea7mOPld/+PLvS lnZ9icq3oa1InotU4n42ZayV+SYueUbrC0oGp1+SPmpM39juy6KfrNpk1Pf4rBTRANq0 Ucn/np3CXWU1FoBpNmNZ8oi//yUyN/x933NJXo+85Fd/x+GNxvPpqyLiRHiNizgHYyDC wViGb08gcQ7pCgch4yZJlEhogV7AxCAo1x/Wlq7EnDSnSk3ihoFnZqaHvnc2z1KqTYDQ H01Zkd7mlwdp8BHlR+MLHR1KlyTNIvJFFqa4rFh80ZZu5DtDqNwaO1HIid09OxqCERZT gGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKWR0Y85NN7RyQ3kGVx0D7iJn85BJCX0K42JtUXarAU=; b=AlJiFweZvN06rcTG+c+3BWWRAm4TQFhmGVXi93M1+6IUDT3OhkXQMJ0EFNNotjU72d cQbKUcX3sWRpoZ4UyNqCwqpyD0luffGs6uBA4MPwTu+eGkHB254q/SEdI/rUcedXD8M/ DGgiO/cDRzS1YGPn4qPhGJUsIh8r6m+wwY6pkysyons2BYQ1UM6LvgwUpwciQHGNxcmU lS7IlynHGgiI7Z5QkcJYWzMY4Q4GtijyP1WZXZPCr8pGxd2R0VgTwomQhBaOroS+qiv6 uH4vvnN/QDiAqTHc64fkGpBpBU43GFLaLTKRcPz5o4qpHm/BaEyI0q3IdPoLGj1nMWeo Y23A== X-Gm-Message-State: AOAM532OM8RPBimYyKO1BU+Ib7diVDL6vXjTCJ1Ygsk67N4RRu939S59 9Bm+HQcebBD+wm1dFmRLArE1XcLzXYpwyc0s9IerDg== X-Google-Smtp-Source: ABdhPJx9yxkxXBkwcUqi9sbNpn5OrCz3LM/gA5pbKkH6GuxZuW6RD9lgnKKdhAxYNPawJLvgPOHidPn+AyZzaBVvkWQ= X-Received: by 2002:aca:2319:: with SMTP id e25mr29645817oie.164.1636762230285; Fri, 12 Nov 2021 16:10:30 -0800 (PST) Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210820155918.7518-1-brijesh.singh@amd.com> <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> In-Reply-To: From: Marc Orr Date: Fri, 12 Nov 2021 16:10:18 -0800 Message-ID: Subject: Re: [PATCH Part2 v5 00/45] Add AMD Secure Nested Paging (SEV-SNP) Hypervisor Support To: Sean Christopherson Cc: Peter Gonda , 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, sathyanarayanan.kuppuswamy@linux.intel.com Content-Type: text/plain; charset="UTF-8" > > > 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. I don't think we should treat the possibility of crashing the host with live VMs nonchalantly. It's a big deal. Doing so has big implications on the probability that any cloud vendor wil bee able to deploy this code to production. And aren't cloud vendors one of the main use cases for all of this confidential compute stuff? I'm honestly surprised that so many people are OK with crashing the host.