From patchwork Tue Apr 19 21:19:21 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Luck, Tony" X-Patchwork-Id: 563423 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DEE1C433F5 for ; Tue, 19 Apr 2022 21:19:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357961AbiDSVWN (ORCPT ); Tue, 19 Apr 2022 17:22:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355594AbiDSVWL (ORCPT ); Tue, 19 Apr 2022 17:22:11 -0400 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5117241309; Tue, 19 Apr 2022 14:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650403168; x=1681939168; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=WhXECTf3/mPf+krPicUL/PhJxyTSG44MJLyCJeT0ht4=; b=ejZpCAkqmvj5PCJ91v7NMJiu4OHKU96vDSFkjEVZVboGFe+kSFhOB8RH iFuydr6kTT1uXLPkLqsX6/BUuMFN1ht5TUirOpcsT8w+dnvJHYZIuAqwN TBNP8c2oNLjAkJW5IUYZJlGn0VThyoul8JMVR1yi3EtiFsph3LnOEIKGd E8amrKICyGoDmPz7ZmAnpVaEAAYTLUqM5Y1urz07Hlrr///jVV4uIwi3G 85lLRCu8BSYdGMd9Xaei42t6skMjb/RSHjo1+3nA4dUYcz9oPviMFuyF+ vHxv93gQFrrxh/wrSo/2t39MAGLfmhIqBUwguhsofvFQ6r/+FlhrybvEq A==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="263338484" X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="263338484" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 14:19:28 -0700 X-IronPort-AV: E=Sophos;i="5.90,273,1643702400"; d="scan'208";a="530778373" Received: from agluck-desk3.sc.intel.com ([172.25.222.78]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Apr 2022 14:19:27 -0700 From: Tony Luck To: "Rafael J. Wysocki" Cc: Len Brown , James Morse , Borislav Petkov , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, patches@lists.linux.dev, Tony Luck Subject: [PATCH] ACPI, APEI, EINJ: Refuse to inject into the zero page Date: Tue, 19 Apr 2022 14:19:21 -0700 Message-Id: <20220419211921.2230752-1-tony.luck@intel.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Some validation tests dynamically inject errors into memory used by applications to check that the system can recover from a variety of poison consumption sceenarios. But sometimes the virtual address picked by these tests is mapped to the zero page. This causes additional unexpected machine checks as other processes that map the zero page also consume the poison. Disallow injection to the zero page. Signed-off-by: Tony Luck --- I picked -EADDRINUSE as a somewhat descriptive error code distinct fromm -EINVAL used elsewhere in EINJ, but I'm not strongly attached to it. Any other non -EINVAL value would be as good an indicator to the validation tests that they shouldn't inject to this address. --- drivers/acpi/apei/einj.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c index 95cc2a9f3e05..d4326ec12d29 100644 --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@ -549,6 +549,9 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2, !arch_is_platform_page(base_addr))) return -EINVAL; + if (is_zero_pfn(base_addr >> PAGE_SHIFT)) + return -EADDRINUSE; + inject: mutex_lock(&einj_mutex); rc = __einj_error_inject(type, flags, param1, param2, param3, param4);