From patchwork Fri Jun 26 15:58:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 11627923 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 97B8992A for ; Fri, 26 Jun 2020 15:59:10 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id F2301204EC for ; Fri, 26 Jun 2020 15:59:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="pMTRSoP0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2301204EC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-19180-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 29955 invoked by uid 550); 26 Jun 2020 15:58:57 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 29837 invoked from network); 26 Jun 2020 15:58:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593187125; bh=MI1bCIGMLcKccd2dmrayi3mwq6PLyLqFmsxPhzVVj+o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pMTRSoP0LXtmeOSgiI76477HiCGpazaJWj4NOXf4jg37wdu7QJRO+hgH7/lbWlegp YbMVEvycZyfYFIw7lvXVRybyHe8zWKkHfI1tp0NnY6Ii7+0F1yeppV9UA9SqboJnmG d43IUvvLg9Bbk9CBd3EtE1y9ClPj/ONI/O8B3hsw= From: Ard Biesheuvel To: linux-arm-kernel@lists.infradead.org Cc: linux-acpi@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, kernel-hardening@lists.openwall.com, Ard Biesheuvel Subject: [PATCH v3 2/2] arm64/acpi: disallow writeable AML opregion mapping for EFI code regions Date: Fri, 26 Jun 2020 17:58:32 +0200 Message-Id: <20200626155832.2323789-3-ardb@kernel.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200626155832.2323789-1-ardb@kernel.org> References: <20200626155832.2323789-1-ardb@kernel.org> MIME-Version: 1.0 Given that the contents of EFI runtime code and data regions are provided by the firmware, as well as the DSDT, it is not unimaginable that AML code exists today that accesses EFI runtime code regions using a SystemMemory OpRegion. There is nothing fundamentally wrong with that, but since we take great care to ensure that executable code is never mapped writeable and executable at the same time, we should not permit AML to create writable mapping. Signed-off-by: Ard Biesheuvel --- arch/arm64/kernel/acpi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 01b861e225b0..455966401102 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -301,6 +301,15 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) pr_warn(FW_BUG "requested region covers kernel memory @ %pa\n", &phys); return NULL; + case EFI_RUNTIME_SERVICES_CODE: + /* + * This would be unusual, but not problematic per se, + * as long as we take care not to create a writable + * mapping for executable code. + */ + prot = PAGE_KERNEL_RO; + break; + case EFI_ACPI_RECLAIM_MEMORY: /* * ACPI reclaim memory is used to pass firmware tables