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 30F36C07E9B for ; Tue, 20 Jul 2021 08:55:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D355561209 for ; Tue, 20 Jul 2021 08:55:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D355561209 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 6E0C78D0002; Tue, 20 Jul 2021 04:55:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66A098D0001; Tue, 20 Jul 2021 04:55:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BD5F8D0002; Tue, 20 Jul 2021 04:55:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 1FBC38D0001 for ; Tue, 20 Jul 2021 04:55:53 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A80AE184793F7 for ; Tue, 20 Jul 2021 08:55:51 +0000 (UTC) X-FDA: 78382358502.10.62105B6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf23.hostedemail.com (Postfix) with ESMTP id 2DF709000722 for ; Tue, 20 Jul 2021 08:55:51 +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 E77E91FDD2; Tue, 20 Jul 2021 08:55:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1626771349; 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=0sf2lL/WSs0Z3IMfWxBFv2FOoeHVxjrvZYcbibsEAXQ=; b=rjEefgeuR84ltJ8ZXtBzBHuUMW0ncRDF92aPilfGqIaO6ZNFt5O5GCnlMtYjaFpn9JB9sl YcRee1g2tejFK9F/DoyVPaSnHJCULeyy6RD+IM79YdoFVI5mXi+wVw5bCMio1t5XYoZrop c6OS3lQqXrt5cm29xsP4/nJsCXorxls= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1626771349; 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=0sf2lL/WSs0Z3IMfWxBFv2FOoeHVxjrvZYcbibsEAXQ=; b=LOMuJq16P+MuFRZQjqwu2B50n2ABUXIzppapWj5frmewT6BrAfiNEr0X2ZZxOrKro3Ubal sl55ZuZJVndRK5DA== 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 3B35513D5E; Tue, 20 Jul 2021 08:55:49 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id K/SiDJWP9mCiHQAAMHmgww (envelope-from ); Tue, 20 Jul 2021 08:55:49 +0000 Date: Tue, 20 Jul 2021 10:55:47 +0200 From: Joerg Roedel To: Andi Kleen Cc: David Rientjes , Borislav Petkov , Andy Lutomirski , 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@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: References: <4e33d22e-330f-c5ba-bc15-08a3298598c5@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e33d22e-330f-c5ba-bc15-08a3298598c5@linux.intel.com> Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=rjEefgeu; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=LOMuJq16; spf=pass (imf23.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: rspam03 X-Rspamd-Queue-Id: 2DF709000722 X-Stat-Signature: 3md1baugoyw8ii6yiipf6k3wzwi4iaf3 X-HE-Tag: 1626771351-317143 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 01:39:48PM -0700, Andi Kleen wrote: > It's actually not just the first X. As I understand there is a proposal for > a new UEFI memory type, that will allow the firmware (and anyone else) to > declare memory regions as accepted in a fine grained manner. Yes, but relying on this means we 1) introduce a dependency to UEFI into booting confidential guests and 2) the decompressor stub in the kernel needs to parse UEFI tables. None of this is a good idea for several reasons. > I don't think it's that bad. If we know what has been validated already > using the memory map, then it's straight forward to check what is a valid > validation request and what is not. Anything that's in a BIOS reserved > region or in a region already marked as validated must be already validated > and and can be rejected (or rather panic'ed). So I don't see the need to > pass a fine grained validation bitmap around. Of course the kernel needs to > maintain something (likely not a bitmap, but rather some form of page flag) > on its own, but it doesn't need to be visible in any outside interfaces. Using page flags means that the information about what is already validated/accepted needs to be carried in another form until the struct-page array is initialized. A lot can happen until then, and every modification in the code that runs before carries the risk of breaking TDX and SNP guests. The Validation Bitmap on the other side is set up on the first boot and kept alive for the rest of the guests life-time (even over kexec/kdump) and will be updated by the allocators in use. This is a much more robust solution than carrying the information in some other way forward until the page array is there. I must admit that I was also voting for a page-flag in the past, but the benefits for robustness, supporting kexec/kdump, and the boot process in general made me re-visit this opinion. > There's one exception to this, which is the previous memory view in crash > kernels. But that's an relatively obscure case and there might be other > solutions for this. Kexec and kdump are not obscure cases, those are real-world requirements for TDX and SNP guests. > I'm not sure about AMD, but in TDX we're certainly have no need to reaccept > after something was shared. Re-validation is needed on AMD, if I am not mistaken AMD hardware even enforces that shared memory is mapped unencrypted and private memory encrypted. Regards, Joerg