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=-3.8 required=3.0 tests=BAYES_00, 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 5BA93C433DB for ; Tue, 2 Feb 2021 22:38:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DB7F364EDA for ; Tue, 2 Feb 2021 22:38:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DB7F364EDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3755B6B0006; Tue, 2 Feb 2021 17:38:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 324DC6B006C; Tue, 2 Feb 2021 17:38:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23AC46B006E; Tue, 2 Feb 2021 17:38:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0157.hostedemail.com [216.40.44.157]) by kanga.kvack.org (Postfix) with ESMTP id 0C5886B0006 for ; Tue, 2 Feb 2021 17:38:00 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BFC791EF1 for ; Tue, 2 Feb 2021 22:37:59 +0000 (UTC) X-FDA: 77774791878.17.waves07_0608e66275ce Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id A071F180D0180 for ; Tue, 2 Feb 2021 22:37:59 +0000 (UTC) X-HE-Tag: waves07_0608e66275ce X-Filterd-Recvd-Size: 3321 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 22:37:58 +0000 (UTC) IronPort-SDR: Py/HUm3H5qN9E3KSZD/s1dx1PdxValawQR3qMnqVnlKFbTRS1UgcIlvhV58SZqn21GWxt5oq7y Tnt7apJSt4SQ== X-IronPort-AV: E=McAfee;i="6000,8403,9883"; a="168621630" X-IronPort-AV: E=Sophos;i="5.79,396,1602572400"; d="scan'208";a="168621630" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Feb 2021 14:37:56 -0800 IronPort-SDR: MjeVdPl5AESuh+fOpZDElVvtftwWGZt/powqX4l2V2rwvtQ28ZxLqKvx+oGDUieHjFMWJhTMEz Ybq2rngdKiFA== X-IronPort-AV: E=Sophos;i="5.79,396,1602572400"; d="scan'208";a="433101259" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Feb 2021 14:37:56 -0800 Date: Tue, 2 Feb 2021 14:37:55 -0800 From: Andi Kleen To: David Rientjes Cc: Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Christoph Hellwig , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Joerg Roedel , x86@kernel.org, linux-mm@kvack.org Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Message-ID: <20210202223755.GM27611@tassilo.jf.intel.com> References: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> 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, Feb 01, 2021 at 05:51:09PM -0800, David Rientjes wrote: > the new PVALIDATE instruction[1]. This sets the Validated flag in the > Reverse Map Table (RMP) for a guest addressable page, which opts into > hardware and firmware integrity protection. This may only be done by the > guest itself and until that time, the guest cannot access the page. Another important point is that we need to reject (panic) any accepts for memory that have already been accepted, to avoid an attacker replacing memory. This means that any memory requires some metadata. > - Any need for validating memory that is not backed by struct page that > needs to be special-cased We may not have struct page for firmware structures for example. > > - Any concerns about this for the DMA layer It would be needed to handle directly assigned devices because they could do DMA to not yet accepted memory. > > One possibility for minimal disruption to the boot entry code is to > require the guest BIOS to validate 4GB and below, and then leave 4GB and > above to be done lazily (the true amount of memory will actually be less > due to the MMIO hole). This would seem fragile to me, requiring Linux to never access any memory >4GB early. Better would be if Linux accepts everything it needs early by itself. -Andi