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 0655FC433DB for ; Fri, 12 Feb 2021 22:39:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 705FA64DF2 for ; Fri, 12 Feb 2021 22:39:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 705FA64DF2 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 0958C8D00A2; Fri, 12 Feb 2021 17:39:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 01F098D0060; Fri, 12 Feb 2021 17:39:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E508A8D00A2; Fri, 12 Feb 2021 17:39:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id C9D8F8D0060 for ; Fri, 12 Feb 2021 17:39:22 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8D1C69991 for ; Fri, 12 Feb 2021 22:39:22 +0000 (UTC) X-FDA: 77811083364.23.dad64_140b20827624 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 7172337604 for ; Fri, 12 Feb 2021 22:39:22 +0000 (UTC) X-HE-Tag: dad64_140b20827624 X-Filterd-Recvd-Size: 2927 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Fri, 12 Feb 2021 22:39:21 +0000 (UTC) IronPort-SDR: NFmID78deYEBVVxKd0Sntmf0FOzmJ/Zue9Ok/DGX9easD6mFggrCZfdVbdNawafH/pza4IC2I6 6HZ8XRhILSNQ== X-IronPort-AV: E=McAfee;i="6000,8403,9893"; a="161629867" X-IronPort-AV: E=Sophos;i="5.81,174,1610438400"; d="scan'208";a="161629867" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2021 14:39:19 -0800 IronPort-SDR: 2Ixvd2sORvLYQz+xNn/QoIUegUvU8cZjeKlvqiI/HR9mXgAleu0u/a6NlIN3Kbv1k163Z/rAdG TByyqzUqUOIw== X-IronPort-AV: E=Sophos;i="5.81,174,1610438400"; d="scan'208";a="437737274" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2021 14:39:19 -0800 Date: Fri, 12 Feb 2021 14:39:18 -0800 From: Andi Kleen To: Peter Zijlstra Cc: Joerg Roedel , David Rientjes , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Christoph Hellwig , Paolo Bonzini , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org Subject: Re: AMD SEV-SNP/Intel TDX: validation of memory pages Message-ID: <20210212223918.GG365765@tassilo.jf.intel.com> References: <7515a81a-19e-b063-2081-3f5e79f0f7a8@google.com> <20210212131907.GI5453@suse.de> <20210212145318.GK5453@suse.de> <20210212152813.GA28884@suse.de> <20210212214205.GF365765@tassilo.jf.intel.com> <20210212215852.GL8912@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210212215852.GL8912@worktop.programming.kicks-ass.net> 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: > But AFAI recursive #VE is entirely possible. The moment #VE reads that > ve_info thing, NMIs can happen, which can trigger another #VE which then > clobbers your stack and we're irrecoverably screwed again. I don't believe we have anything currently in the NMI handler that would trigger #VE. While some operations may need TDCALL (like MSR accesses) those should be all directly hooked. Also in general to avoid clobbering your stack you would just need to make sure to adjust the IST stack before you do anything that could cause another #VE. -Andi