From patchwork Fri Mar 24 13:24: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: 9642815 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 872F2601E9 for ; Fri, 24 Mar 2017 13:24:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7551320008 for ; Fri, 24 Mar 2017 13:24:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 69E1227E5A; Fri, 24 Mar 2017 13:24:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 53CB720008 for ; Fri, 24 Mar 2017 13:24:54 +0000 (UTC) Received: (qmail 19839 invoked by uid 550); 24 Mar 2017 13:24:45 -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 19508 invoked from network); 24 Mar 2017 13:24:41 -0000 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=zxQ5vquC/dh00BbVfL5jk/2fRGRP4TAoGv2MNGxi6e8=; b=DYphlG4+gCPNdZ5xXhkijcQ1Ps4J99zIDj2MHCR9wQBZDbaw/8mu8olJ42dnpTBWpp DQJoOTGYWEEgGdZwqEMpgXJykGTiL7dgonQeu48uBHfKa6L+mOebgzBwcXPCk9APY/l8 FtyGnw9H6lVS1o9Bxl72VMgKJzG/E2Ol4M2z0= 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=zxQ5vquC/dh00BbVfL5jk/2fRGRP4TAoGv2MNGxi6e8=; b=nrV8e11sbttr8w0x+yXnMaWC5Vdn6ynI1018UJBWtwd5ScOAJ0GzhEJTdZvpeWmiLU /UzK+Zxt05/H/GaoWHX4TNy0HzCFfJlBht7c6qUvBPY9k5lunU5LDsR4unSngjcdtfRl M8kpXG1tXPFFLQGECmYuKOLrCtlwcg4lLwPwceZ9mxnMdAaOIoJAdpQftjrMHq0gVDUP q+BeOiVXaUeGRGdN/Pfqq48m2UUZDFC6PqpH6UaTia9BHeA9ftVrCFJ0mwiq15qVjNjH gxLblXl02CbbDJDvkeyt1nCyR7AgQr9Vx+lDFDZAZOMLES3/rOP9axbnY0sjS5u73UVr yyQg== X-Gm-Message-State: AFeK/H1wlEjykU+cXLS4iILooLtarf2N2UmN94AWBg0lxMMbba/9xbLjWl7TdAq6sObE335W X-Received: by 10.28.87.6 with SMTP id l6mr2952121wmb.109.1490361869701; Fri, 24 Mar 2017 06:24:29 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, matt@codeblueprint.co.uk, leif.lindholm@linaro.org, rfranz@cavium.com, mingo@kernel.org, bp@alien8.de, mark.rutland@arm.com, kernel-hardening@lists.openwall.com, Ard Biesheuvel Date: Fri, 24 Mar 2017 13:24:10 +0000 Message-Id: <20170324132410.16628-5-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170324132410.16628-1-ard.biesheuvel@linaro.org> References: <20170324132410.16628-1-ard.biesheuvel@linaro.org> Subject: [kernel-hardening] [PATCH 4/4] ef/libstub: arm/arm64: randomize the base of the UEFI rt services region X-Virus-Scanned: ClamAV using ClamSMTP 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 | 48 ++++++++++++++------ 1 file changed, 35 insertions(+), 13 deletions(-) diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c index 6f522e3091af..eb5225884098 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 efi_virt_base = EFI_RT_VIRTUAL_BASE; + efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image, void **__fh) { @@ -209,6 +225,25 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, efi_random_get_seed(sys_table); + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && !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) { + efi_virt_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), @@ -238,18 +273,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; @@ -299,7 +322,6 @@ 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; efi_memory_desc_t *in, *prev = NULL, *out = runtime_map; int l;