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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9F8BC07E95 for ; Tue, 20 Jul 2021 09:11:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CFB46120F for ; Tue, 20 Jul 2021 09:11:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CFB46120F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D0F168D0002; Tue, 20 Jul 2021 05:11:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CBE7D8D0001; Tue, 20 Jul 2021 05:11:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B38628D0002; Tue, 20 Jul 2021 05:11:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 87DDC8D0001 for ; Tue, 20 Jul 2021 05:11:09 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0D69E8248047 for ; Tue, 20 Jul 2021 09:11:08 +0000 (UTC) X-FDA: 78382397016.06.43BEF90 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf07.hostedemail.com (Postfix) with ESMTP id 80D57100B1DD for ; Tue, 20 Jul 2021 09:11:07 +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-out2.suse.de (Postfix) with ESMTPS id 6D2971FD3E; Tue, 20 Jul 2021 09:11:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1626772266; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+kd/u8CU4q26Few9zjEdRRSxYLzHoRL5c+SvecSD1cU=; b=tzc14/s6q326MAX/80brC9WF6A7XgWSXeSSLmj6PNY7rXZZJPeRmGz5hFedadMeZVN8/AK MlPmOGBhEk9b5LHvJAzeDhZhRgqPlAmN3B+R/kM2S/OKUnmT3kwx5DLLk0NLj7VOamZZwc MJUrz0ElEaCUAbtvWL3GF+HeVBWNQP8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1626772266; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+kd/u8CU4q26Few9zjEdRRSxYLzHoRL5c+SvecSD1cU=; b=uwuvTENOmHD9IJ/WMdd1vHZ0TdBeHTnAtN5Hak03B42Mkn6NeWYykYxmx/Oe++jT7iAlPR 5Zag7Dpmx5JxKDCw== 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 B1A3E13C89; Tue, 20 Jul 2021 09:11:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id VtGuKSmT9mD1IgAAMHmgww (envelope-from ); Tue, 20 Jul 2021 09:11:05 +0000 Date: Tue, 20 Jul 2021 11:11:04 +0200 From: Joerg Roedel To: Andi Kleen Cc: Erdem Aktas , Andy Lutomirski , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86 , linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="tzc14/s6"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=uwuvTENO; spf=pass (imf07.hostedemail.com: domain of jroedel@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=jroedel@suse.de; dmarc=none X-Rspamd-Server: rspam02 X-Stat-Signature: ax1d4gm535bdsds7m5gkacctardzsaiz X-Rspamd-Queue-Id: 80D57100B1DD X-HE-Tag: 1626772267-787101 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, Jul 19, 2021 at 10:17:36PM -0700, Andi Kleen wrote: > For non crash kexec it's fine to reaccept/validate memory because we don't > care about the old contents anymore, except for the kernel itself and > perhaps your stack/page tables. So something very simple is enough for that > too. I am not sure how it is implemented in TDX hardware, but for SNP the guest _must_ _not_ double-validate or even double-invalidate memory. What I sent here is actually v2 of my proposal, v1 had a much more lazy approach like you are proposing here. But as I learned what can happen is this: * Hypervisor maps GPA X to HPA A * Guest validates GPA X Hardware enforces that HPA A always maps to GPA X * Hypervisor remaps GPA X to HPA B * Guest lazily re-validates GPA X Hardware enforces that HPA B always maps to GPA X The situation we have now is that host pages A and B are validated for the same guest page, and the hypervisor can switch between them at will, without the guest being able to notice it. This can open various attack vectors from the hypervisor towards the guest, like tricking the guest into a code-path where it accidentially reveals its secrets. For that reason the guest needs to know at any time whether a given page has already been validated/accepted. And the guest needs to pass along this fine-grained information even in the case of kexec/kdump. > If the device filter is active it won't. We are not going to pohibit dma_alloc_coherent() in SNP guests just because we are too lazy to implement memory re-validation. Regards, Joerg