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 4D904C07E9B for ; Tue, 20 Jul 2021 22:01:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8D5960FF2 for ; Tue, 20 Jul 2021 22:01:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8D5960FF2 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 459FE6B0011; Tue, 20 Jul 2021 18:01:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 40B766B0036; Tue, 20 Jul 2021 18:01:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AB426B006C; Tue, 20 Jul 2021 18:01:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id 01FD46B0011 for ; Tue, 20 Jul 2021 18:01:33 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6DB8218081 for ; Tue, 20 Jul 2021 22:01:32 +0000 (UTC) X-FDA: 78384338424.29.D7ECD02 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf04.hostedemail.com (Postfix) with ESMTP id 7067E500032F for ; Tue, 20 Jul 2021 22:01:31 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10051"; a="211053531" X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="211053531" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 15:01:20 -0700 X-IronPort-AV: E=Sophos;i="5.84,256,1620716400"; d="scan'208";a="415387981" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2021 15:01:19 -0700 Date: Tue, 20 Jul 2021 15:01:13 -0700 From: Andi Kleen To: Erdem Aktas Cc: Andy Lutomirski , Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , "Peter Zijlstra (Intel)" , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , the arch/x86 maintainers , linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <20210720220113.GA535804@tassilo.jf.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf04.hostedemail.com; dkim=none; spf=none (imf04.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 192.55.52.115) smtp.mailfrom=ak@linux.intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Rspamd-Server: rspam05 X-Stat-Signature: euu3oa884ngqkf77f6i9dry14yq193it X-Rspamd-Queue-Id: 7067E500032F X-HE-Tag: 1626818491-511 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 Tue, Jul 20, 2021 at 12:54:16PM -0700, Erdem Aktas wrote: > Now let's say the kernel wants to access a page for the first time, or > after a kexec it wants to make sure all the pages are private. it > needs to call tdx_hcall_gpa_intent or tdg_accept_page individually. > If the page is already accepted, tdg_accept_page does not return any > error in the current implementation in v3. Depending on how this page > is being used, it's content is now "not zeroed" as opposed to what it > is being expected. Converting this to an attack is not trivial but > possible. You mean when the TDVF is changed? In this case the unaccepted memory will be a different memory type, so not lazy accept enabled kernels wouldn't use it. > > I did not see any #VE implementation to handle SEPT violations when a > page is in PENDING state. I am assuming that this needs to be > supported at some point (If not then we need to discuss the use cases > for such support). We actually plan to disable those #VEs, to avoid any problems with the system call gap. Instead the plan is that the kernel will know in advance what memory has been accepted or not, and accept it before touching. -Andi