Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1195541pxb; Fri, 21 Jan 2022 12:00:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJyf+w3fEw7rF2Jd+0HtRB4eEjgrpvWTj2GDoGcCM6gwSllffZrj857AxgJ3u+GB0ZcyHoE0 X-Received: by 2002:a17:90a:5210:: with SMTP id v16mr2266571pjh.107.1642795255282; Fri, 21 Jan 2022 12:00:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642795255; cv=none; d=google.com; s=arc-20160816; b=H+vl4UHq1w/aZ1HbXAXxD/Zamqc87/9i8IzPCR36FWOncY8aYijjDa1G/79vMLDDc8 Xx7nKEuk4607whtT6VNia9nbJRWB675hl84iESRUwigXpRVzaqaQzziSqpcONyD8qbb7 W8bnoami0a4x33iCoF3ue8AS0n3hFAOusVhpGy49GFvGf5lNDlXHYslkijQErKFQ2kdo sIE6IFKS1BQyvsufjmbYa9nJtbE7GL3qvWkgWh/zkFfq55Wxin/kNrbQw39TzgjirYUY oDNLtafqqJbv5srozWMyH8i5udliskczrRCZx8GWuKLSgcR80ug4ub7HIUnC45Fj0CSd 0cHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to:dkim-signature; bh=b+m0MNPzpe1jd0O8xLL0XcPd4B6hv6ZyRTxiUsE0WJ8=; b=CTuwGimnuKmOc1Se25AdaHa0newlof/EVVW+xLnHzlTMP4iUT08xrI/iLlz4OZEePS BRZQU1xltqK0kVJtwH79Z7KitBJBi87iYX62tXKv0Tqoby2XDWYq5lF+oWPscU+m2HGS tO9Aht++jTLlLe3ltGpS/MM0OhZHoVZUbYtrhXFj6Pl6qN4uFCwSGLwwiM1Y2hQ0OOaT QD4hp2esvsqRAAJ5IzJ5/bLvemdLZPMArvWBzoe3Dq4xOJQYQcRB0DW5KIEXrwoRORrV wJ8GTbZh7BMxi03wxPf37yNHhxJieE8sowcAvXzveK+8qfOnXexUVuZ1FtLtJ7pnDNlJ QC7Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NypGMbBb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d7si6949475pln.220.2022.01.21.12.00.42; Fri, 21 Jan 2022 12:00:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NypGMbBb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230021AbiASTvg (ORCPT + 99 others); Wed, 19 Jan 2022 14:51:36 -0500 Received: from mga06.intel.com ([134.134.136.31]:42165 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357132AbiASTvJ (ORCPT ); Wed, 19 Jan 2022 14:51:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642621869; x=1674157869; h=to:cc:references:from:subject:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=IaekLBKy12A7TazDiSD3oKpEQKdqYzsh5NJ4fpWQ560=; b=NypGMbBbnupJvXsrtP1e1POQLcoNoTVSebwZjRAXwr7qizAt7QCqFCfW K5Xqm2rr2w4zKJROz/4KOkIKTND8owdN+l9llmSqpSa8m1a3/AF1P/7mY bXZywQ9r2eJVZ4ehmm0+bcDTF54HHacKPvn3nhkg4xft9vTETC+tUW65j zrVmy5wFM8TI0ZNYJNQvHt5T+vBpv9k9xBDybdGcEPvJq9aJTK65vQqq3 2yUyCSRKWpY6BtZwyskFFNoENNXR3bHtoiPWsm3DnYe8Dhs4p7gZiY+q2 +JOgiAbd5iIEFYrDzILa6RT/sgIxiPOxy9Q9LBO5kO6H/8jb7XYhYdatE Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10231"; a="305909489" X-IronPort-AV: E=Sophos;i="5.88,300,1635231600"; d="scan'208";a="305909489" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2022 11:51:08 -0800 X-IronPort-AV: E=Sophos;i="5.88,300,1635231600"; d="scan'208";a="475264686" Received: from rbschuch-mobl.amr.corp.intel.com (HELO [10.212.238.54]) ([10.212.238.54]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jan 2022 11:51:08 -0800 To: Reinette Chatre , tony.luck@intel.com, dave.hansen@linux.intel.com, jarkko@kernel.org, tglx@linutronix.de, bp@alien8.de, luto@kernel.org, mingo@redhat.com, linux-sgx@vger.kernel.org, x86@kernel.org Cc: linux-kernel@vger.kernel.org References: From: Dave Hansen Subject: Re: [PATCH] x86/sgx: Add poison handling to reclaimer Message-ID: <9cefa244-9830-c158-6112-b2c61a464632@intel.com> Date: Wed, 19 Jan 2022 11:51:05 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/22 3:05 PM, Reinette Chatre wrote: > The machine check recovery handling in SGX added the changes > listed below to the freeing of pages in sgx_free_epc_page(). > The SGX reclaimer contains an open coded version of > sgx_free_epc_page() and thus did not obtain the changes in > support of poison handling. I was trying to decide if this is an urgent fix or not. A more crisp problem statement might have helped in the changelog. But, from what I can tell, the most probable troublesome scenario here would be something like: 1. Machine check (#MC) occurs (asynchronous, !MF_ACTION_REQUIRED) 2. arch_memory_failure() called is eventually 3. (SGX) page->poison set to 1 4. Page is reclaimed 5. Page added to normal free lists by sgx_reclaim_pages() ^ This is the bug 6. Page is reallocated by some innocent enclave, a second (synchronous) in-kernel #MC is induced, probably during EADD instruction. ^ This is the fallout from the bug #6 is unfortunate and can be avoided if this patch is applied. Basically, this patch ensures that a bad enclave page is isolated quickly and causes a minimal amount of collateral damage. Is this a valid summary? The SGX reclaimer code lacks page poison handling in its free path. This can lead to completely avoidable machine checks if a poisoned page is freed and reallocated instead of being isolated.