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 5BA9AC433EF for ; Tue, 16 Nov 2021 16:44:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D2724613A7 for ; Tue, 16 Nov 2021 16:44:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D2724613A7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 3649F6B007B; Tue, 16 Nov 2021 11:44:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3130A6B007D; Tue, 16 Nov 2021 11:44:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B46A6B007E; Tue, 16 Nov 2021 11:44:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id 0E37F6B007B for ; Tue, 16 Nov 2021 11:44:21 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AE09518106137 for ; Tue, 16 Nov 2021 16:44:20 +0000 (UTC) X-FDA: 78815366280.21.E76FA73 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id C567CB004EB4 for ; Tue, 16 Nov 2021 16:37:30 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B5E1C212C3; Tue, 16 Nov 2021 13:02:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1637067729; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HZbn//2jHoLXpUwrCvvkW6DSHLSoB+3INvS/r2/24sc=; b=FYRTscp/uk3I5t9ARhqDS+oQtcnEQmCncTzGPO3Hv9HK0a/NVU4TCKluaVO5R/7cGPqGbW LEx7IOGROGGptHOqKmq0pFGJfJkdtNfSh5LJ0HAz9Fwe6SfxQtUxJJ6h3bEnl8NYqni85w fHUT8gn/GEU0ASDMIXnyfZqwO8Oq4AI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1637067729; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HZbn//2jHoLXpUwrCvvkW6DSHLSoB+3INvS/r2/24sc=; b=Ldn19b969Jzd4AIEqkaYx8K4ZPFYTGGbLwIV0KErqmeO5oTXcggS3KFfP/xdUBfurLUSgP B8CPXQUhz4RySSAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7D46E13BA3; Tue, 16 Nov 2021 13:02:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id HRJfHNCrk2HmbwAAMHmgww (envelope-from ); Tue, 16 Nov 2021 13:02:08 +0000 Date: Tue, 16 Nov 2021 14:02:06 +0100 From: Joerg Roedel To: Sean Christopherson Cc: "Dr. David Alan Gilbert" , Borislav Petkov , 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 , 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=iso-8859-1 Content-Disposition: inline In-Reply-To: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="FYRTscp/"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Ldn19b96; spf=pass (imf25.hostedemail.com: domain of jroedel@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=jroedel@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C567CB004EB4 X-Stat-Signature: 5xpodry35xpdyz9xcnbyesxztd3fi7em X-HE-Tag: 1637080650-19113 Content-Transfer-Encoding: quoted-printable 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 Mon, Nov 15, 2021 at 06:26:16PM +0000, Sean Christopherson wrote: > No, because as Andy pointed out, host userspace must already guard agai= nst a bad > GPA, i.e. this is just a variant of the guest telling the host to DMA t= o a GPA > that is completely bogus. The shared vs. private behavior just means t= hat when > host userspace is doing a GPA=3D>HVA lookup, it needs to incorporate th= e "shared" > state of the GPA. If the host goes and DMAs into the completely wrong = HVA=3D>PFN, > then that is a host bug; that the bug happened to be exploited by a bug= gy/malicious > guest doesn't change the fact that the host messed up. The thing is that the usual checking mechanisms can't be applied to guest-private pages. For user-space the GPA is valid if it fits into the guest memory layout user-space set up before. But whether a page is shared or private is the guests business. And without an expensive reporting/query mechanism user-space doesn't have the information to do the check. A mechanism to lock pages to shared is also needed, and that creates the next problems: * Who can release the lock, only the process which created it or anyone who has the memory mapped? * What happens when a process has locked guest regions and then dies with SIGSEGV, will its locks on guest memory be released stay around forever? And this is only what comes to mind immediatly, I sure there are more problematic details in such an interface. Regards, --=20 J=F6rg R=F6del jroedel@suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 N=FCrnberg Germany =20 (HRB 36809, AG N=FCrnberg) Gesch=E4ftsf=FChrer: Ivo Totev