From patchwork Tue Apr 4 16:09:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 96752 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp266262qgd; Tue, 4 Apr 2017 09:09:35 -0700 (PDT) X-Received: by 10.84.247.23 with SMTP id n23mr29870519pll.39.1491322175352; Tue, 04 Apr 2017 09:09:35 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92si17938993plc.124.2017.04.04.09.09.35; Tue, 04 Apr 2017 09:09:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932146AbdDDQJc (ORCPT + 25 others); Tue, 4 Apr 2017 12:09:32 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:32845 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932111AbdDDQJa (ORCPT ); Tue, 4 Apr 2017 12:09:30 -0400 Received: by mail-wr0-f176.google.com with SMTP id w43so218105467wrb.0 for ; Tue, 04 Apr 2017 09:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=PZdrJC3hc+ZZkSqJi3ylGxsX1QnpS4xBhPA2gAGn/IU=; b=EY6Z9mldfUxUXy/IUHuNSfkMm5OXsiYyGGN+a6oYTPAJnjZtjg37hH80lG8QRwzvJf Q2kMoIbcEFDeJE2TsAO2X+HL7PJ3AEPGSYdXLtKEm3Th8G2H02t6k5zj/yBEjkYk4EtM P5v6hvlpBGjD3MAz6bcItAO4xbYajJcYS/UwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=PZdrJC3hc+ZZkSqJi3ylGxsX1QnpS4xBhPA2gAGn/IU=; b=WIaiVtDFtEJihDQR7HB+61gbsUKQoC5RB51rjt+9dLDr2xnNkASTvJozFwqzj6X2b4 JHL421ItMKXWJtBz5Hqmb9JmttxoVjcQY8FKsdr+lSo/Xi0hMZUhB0Dyqx11qzIRo3By aulQ3vRaqvZyLjBx+2ZYVhcFbwCElhk1QbqAUvVtlz2AB0UO+pjsoTqgMUjo1ywtDxYe tVPacFuZ+VVwa1lJmvJL108DfYYZH28QNrgrhjB2Aso7Kvub5Ks6CJ3dl4R5krv2JvSw 25CSHNzlFBlaZV1jOgTXZGxYX3v2O90WwzhJGSDnzPeuJNo4Ucm6DTXQbfFW7J0Bkq/b NYDg== X-Gm-Message-State: AFeK/H0MdzLU09378SX5+sJAweq25Z0acXZ4WB3ydZeg6Ui/3O6xrY1HhXCayN8YOC83km41 X-Received: by 10.223.170.66 with SMTP id q2mr20464762wrd.179.1491322168631; Tue, 04 Apr 2017 09:09:28 -0700 (PDT) Received: from localhost.localdomain ([160.163.145.113]) by smtp.gmail.com with ESMTPSA id u66sm19003333wmd.24.2017.04.04.09.09.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 09:09:27 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: matt@codeblueprint.co.uk, mark.rutland@arm.com, roy.franz@cavium.com, rruigrok@codeaurora.org, leif.lindholm@linaro.org, jhugo@codeaurora.org, evgeny.kalugin@intel.com, eugene@hp.com, bp@alien8.de, bhsharma@redhat.com, bhe@redhat.com, Ard Biesheuvel , linux-kernel@vger.kernel.org Subject: [PATCH 12/12] ef/libstub: arm/arm64: Randomize the base of the UEFI rt services region Date: Tue, 4 Apr 2017 17:09:10 +0100 Message-Id: <20170404160910.28115-3-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170404160910.28115-1-ard.biesheuvel@linaro.org> References: <20170404160245.27812-1-ard.biesheuvel@linaro.org> <20170404160910.28115-1-ard.biesheuvel@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update the allocation logic for the virtual mapping of the UEFI runtime services to start from a randomized base address if KASLR is in effect, and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL. This makes it more difficult to predict the location of exploitable data structures in the runtime UEFI firmware, which increases robustness against attacks. Note that these regions are only mapped during the time a runtime service call is in progress, and only on a single CPU at a time, bit give the lack of a downside, let's enable it nonetheless. Cc: Ingo Molnar Cc: Borislav Petkov Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/arm-stub.c | 49 ++++++++++++++++++++++++--------- 1 file changed, 36 insertions(+), 13 deletions(-) -- 2.9.3 diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c index 657bb72c9e0b..1e45ec51b094 100644 --- a/drivers/firmware/efi/libstub/arm-stub.c +++ b/drivers/firmware/efi/libstub/arm-stub.c @@ -18,6 +18,22 @@ #include "efistub.h" +/* + * This is the base address at which to start allocating virtual memory ranges + * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use + * any allocation we choose, and eliminate the risk of a conflict after kexec. + * The value chosen is the largest non-zero power of 2 suitable for this purpose + * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can + * be mapped efficiently. + * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split, + * map everything below 1 GB. (512 MB is a reasonable upper bound for the + * entire footprint of the UEFI runtime services memory regions) + */ +#define EFI_RT_VIRTUAL_BASE SZ_512M +#define EFI_RT_VIRTUAL_SIZE SZ_512M + +static u64 virtmap_base = EFI_RT_VIRTUAL_BASE; + efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image, void **__fh) { @@ -213,6 +229,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, efi_random_get_seed(sys_table); + if (!nokaslr()) { + /* + * Randomize the base of the UEFI runtime services region. + * Preserve the 2 MB alignment of the region by taking a + * shift of 21 bit positions into account when scaling + * the headroom value using a 32-bit random value. + */ + u64 headroom = TASK_SIZE - EFI_RT_VIRTUAL_BASE - + EFI_RT_VIRTUAL_SIZE; + u32 rnd; + + status = efi_get_random_bytes(sys_table, sizeof(rnd), + (u8 *)&rnd); + if (status == EFI_SUCCESS) { + virtmap_base = EFI_RT_VIRTUAL_BASE + + (((headroom >> 21) * rnd) >> (32 - 21)); + } + } + new_fdt_addr = fdt_addr; status = allocate_new_fdt_and_exit_boot(sys_table, handle, &new_fdt_addr, efi_get_max_fdt_addr(dram_base), @@ -242,18 +277,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, return EFI_ERROR; } -/* - * This is the base address at which to start allocating virtual memory ranges - * for UEFI Runtime Services. This is in the low TTBR0 range so that we can use - * any allocation we choose, and eliminate the risk of a conflict after kexec. - * The value chosen is the largest non-zero power of 2 suitable for this purpose - * both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can - * be mapped efficiently. - * Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split, - * map everything below 1 GB. - */ -#define EFI_RT_VIRTUAL_BASE SZ_512M - static int cmp_mem_desc(const void *l, const void *r) { const efi_memory_desc_t *left = l, *right = r; @@ -303,7 +326,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size, unsigned long desc_size, efi_memory_desc_t *runtime_map, int *count) { - u64 efi_virt_base = EFI_RT_VIRTUAL_BASE; + u64 efi_virt_base = virtmap_base; efi_memory_desc_t *in, *prev = NULL, *out = runtime_map; int l;