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 EF8F6C433FE for ; Fri, 12 Nov 2021 20:38:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 827D0610F8 for ; Fri, 12 Nov 2021 20:38:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 827D0610F8 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 CE0646B0075; Fri, 12 Nov 2021 15:38:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C694E6B0078; Fri, 12 Nov 2021 15:38:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A96656B007B; Fri, 12 Nov 2021 15:38:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 933756B0075 for ; Fri, 12 Nov 2021 15:38:05 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4FC495BE1A for ; Fri, 12 Nov 2021 20:38:05 +0000 (UTC) X-FDA: 78801440130.13.566F738 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf02.hostedemail.com (Postfix) with ESMTP id 698537001701 for ; Fri, 12 Nov 2021 20:37:58 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id x64so9479709pfd.6 for ; Fri, 12 Nov 2021 12:38:04 -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=Y3lkkCoH31qkZVjCCR/E7oVCSTtI0bujwimpGP/k3sA=; b=StN5hrm4hrP1PWbwCsad9xfHaY2mzd5NEqWZg7LjTXOZ+9O/G/vIJYTO874W0+OU7r 02e49SdXYQFdhvavIZ0/Bgod8n3+ZPrZX9t5taGeiSaOJLczRlhgUsuiblb4EI1jSGr+ NZWJGqOvikolAUKZstOfQnFkDiHpXy5LCm6OqCEgEmOlPoBi5L0xsKFKfGSbbt3WMQV8 erURs1+sPIwc1Q6/kxoa4st6fVGOE95gxJmsH2gSpF6ktwp5Vr5qTsL65Ap/O7SZjEtY by6NXYeQrLcf7ijygDNbUjhgeRcyqonZeu3bZGNg0RmLBhW2BQofEnHhp2HQOsR5EwSx 4itw== 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=Y3lkkCoH31qkZVjCCR/E7oVCSTtI0bujwimpGP/k3sA=; b=JtzHtFRRkSrvE+OxYsAo2z2Ecjf7Hoq12z6m+h3JnnUyfJ2SqNiLfmQnvEJxg+yOT6 BbDNvrqT+Moc/+7+tqrYRmDafWI9J86NzDruvWGCsg/5vb7CgudfCZrrxR9s8309krYe Bnuk0lZ4nBXJezf5AqjsbIY5WZVLHMEpmxuwBlGG8lRHQnOcmPb/V/eumvUaY7rqQ3Wz v2O8fF2dYk4fm2okDzR10tLRQRz3EHT1rrki48iBsP/EN69KnhNiIyBRXmmacLB01rwL 3mlKl8y6NlSZSxG7thCSWOkDppAz/tafW8ugfQjz38Jf9BDsKwfjPrvBGgo6RFnRuroF mtEA== X-Gm-Message-State: AOAM530sTjBIPLxXVJrB0Eja7NWconbctagWYguZ1bzsy23TjMgndCeQ FYgN8+HqR4sv4w+lEB9wmAK7nA== X-Google-Smtp-Source: ABdhPJzHagE7e/zPwAVgF1qVOvwX2AZJfu6+gEOKjv7ntsak1VhR4NZPtnwdBehCWj1cbnfgo9fw4g== X-Received: by 2002:a63:9508:: with SMTP id p8mr11607250pgd.413.1636749483738; Fri, 12 Nov 2021 12:38:03 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id qe12sm12567812pjb.29.2021.11.12.12.38.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Nov 2021 12:38:02 -0800 (PST) Date: Fri, 12 Nov 2021 20:37:59 +0000 From: Sean Christopherson To: Borislav Petkov Cc: Dave Hansen , Peter Gonda , 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: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=StN5hrm4; spf=pass (imf02.hostedemail.com: domain of seanjc@google.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 698537001701 X-Stat-Signature: axjfbgc6x5aianh37156cx6xmiydghj6 X-HE-Tag: 1636749478-916994 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, Borislav Petkov wrote: > On Fri, Nov 12, 2021 at 07:48:17PM +0000, Sean Christopherson wrote: > > Yes, but IMO inducing a fault in the guest because of _host_ bug is wrong. > > What do you suggest instead? Let userspace decide what is mapped shared and what is mapped private. 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. - if kernel accesses guest private memory, it does BUG/panic/oops[*] - if guest accesses memory with the incorrect C/SHARED-bit, it gets killed. This is the direction KVM TDX support is headed, though it's obviously still a WIP. And ideally, to avoid implicit conversions at any level, hardware vendors' ABIs define that: a) All convertible memory, i.e. RAM, starts as private. b) Conversions between private and shared must be done via explicit hypercall. Without (b), userspace and thus KVM have to treat guest accesses to the incorrect type as implicit conversions. [*] Sadly, fully preventing kernel access to guest private is not possible with TDX, especially if the direct map is left intact. But maybe in the future TDX will signal a fault instead of poisoning memory and leaving a #MC mine.