From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AA912C80 for ; Fri, 12 Nov 2021 18:35:28 +0000 (UTC) Received: from zn.tnic (p200300ec2f10ce00d687ada8c7fa1c88.dip0.t-ipconnect.de [IPv6:2003:ec:2f10:ce00:d687:ada8:c7fa:1c88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id A5E241EC03AD; Fri, 12 Nov 2021 19:35:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1636742126; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=JmA2cfYq/RSf+0ammQvVqrSmh6MfYoVev6SVnovd+no=; b=ECPlX/c1Pahyqr2/in+oog3PPH5hgi86QxIT/3FK6k2C1LOWpJ48d8oSC02yYxCr0jhJpC Zotq7GNmwIX01kKhehALvprcqEpVGp8V42oRd4RF5oNa3hrFQAHydUx41Fv9E/GGctyuyp VNaqgHj42R1Ut+uwWiG6v4Pp6CoP96g= Date: Fri, 12 Nov 2021 19:35:19 +0100 From: Borislav Petkov To: Dave Hansen Cc: 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 , Sean Christopherson , 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> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <061ccd49-3b9f-d603-bafd-61a067c3f6fa@intel.com> On Fri, Nov 12, 2021 at 09:59:46AM -0800, Dave Hansen wrote: > Or, is there some mechanism that prevent guest-private memory from being > accessed in random host kernel code? So I'm currently under the impression that random host->guest accesses should not happen if not previously agreed upon by both. Because, as explained on IRC, if host touches a private guest page, whatever the host does to that page, the next time the guest runs, it'll get a #VC where it will see that that page doesn't belong to it anymore and then, out of paranoia, it will simply terminate to protect itself. So cloud providers should have an interest to prevent such random stray accesses if they wanna have guests. :) > This sounds like a _possible_ opportunity for the guest to do some extra > handling. It's also quite possible that this #VC happens in a place > that the guest can't handle. How? It'll get a #VC when it first touches that page. I'd say the #VC handler should be able to deal with it... Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette