From patchwork Sun Oct 22 14:14:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 116632 Delivered-To: patch@linaro.org Received: by 10.140.22.164 with SMTP id 33csp3680271qgn; Sun, 22 Oct 2017 07:15:15 -0700 (PDT) X-Received: by 10.98.32.206 with SMTP id m75mr10570227pfj.231.1508681715859; Sun, 22 Oct 2017 07:15:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508681715; cv=none; d=google.com; s=arc-20160816; b=MaKEdAsSH1kku0E3dDuNOIGHvxcvPJC440+DEEQ7ykpJ/1hVxJWkXTGtafLqh2QBew wNlXzj5RQvENn5xvdHJCnLh1KuJnNxohgS7x1sPg+vOmfl7+UVQy6zgreGYczLTMn+Xr FumDTZPn9Ou/1QYe9IRL+iyioHTRZTiWJcIk6rtDmEAyR7fNDMDCL+fGwglIyfg5BJt9 9/8wJkk/shU6EQkrEWVwalKguvW3g4mHKZpkJFqsnEid80XfUVjUthyVNJ1ZoL+7FuUa 7DiJqjRaSbTnemJ9ueGvxkcD67YSLaMHezew5WdkGvBe+abSFD2qaATJbu1ZrkUG0GgX eJng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=7/bZEevLQs4qL1bVusxX1iccalmF+A7X9SaJDKRjE4Q=; b=ArZkyhZyU7He4mCW4BvtPAZO+tBPxklsBkM64FpwjMI7M5xSAg9oet044di1ZQGJlQ yzyp+7TyJtVbF6Kpu604ywoiDQuiLPET/GaCgb6MxWbeQ/M8++PRX0LCrHjQw3mPa5hX ajSU9WWw8WGfBQly/TOybE2MmG3xbXmgAN2jSbF2s2tt3onk3lbOCyXVU3p+tcPwaipx 64VytjHjBcRtoNRK/IkbovyqEsmyIjBPIZKMD2vG+xye4pzhMZbqFSqknJtpzCVtFU/W lUI8rcNsW7qV2qjmQUiUxvvx2+xnfzZZshcwjjS9ulv9CiqK19IUmWG+Ju0Cyftatk0K HlIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=gmbAx+3i; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i85si3880369pfj.398.2017.10.22.07.15.15; Sun, 22 Oct 2017 07:15:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=gmbAx+3i; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751108AbdJVOPO (ORCPT + 2 others); Sun, 22 Oct 2017 10:15:14 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:44968 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbdJVOPN (ORCPT ); Sun, 22 Oct 2017 10:15:13 -0400 Received: by mail-wm0-f68.google.com with SMTP id 196so5668200wma.1 for ; Sun, 22 Oct 2017 07:15:13 -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; bh=Th6fTNmTuhA7xR6V+V3KmOnvODOndxe91Sgr2vl8XAI=; b=gmbAx+3ibm6W7OLdoyoczGvPXuHmKQnBLUMj9JTSF+UJjZ9ZYFJrGPJZ+MVnpBmLU1 XUJv8wzU5u32zipMoxCrajU4yXslbkbbA52IWp/O7BonHGm3qPXDw/AwsjUxr9TTxpIG X2aHWRL95BD5lneYR0wphjXIG36zmx2VzBXAI= 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; bh=Th6fTNmTuhA7xR6V+V3KmOnvODOndxe91Sgr2vl8XAI=; b=uHxsm/tREYoHxFfbUEPH8qi9j34CSqptyf/mC0O6BXYlygwcut1VCJ1w/rjne035Z0 PHLzyk7pwAvGTJhQayD5A7AJ1YuZeuz8QSTbutrrPfKCC0SzeX8qf88Ihltax5Xt+8z/ cghx6ULpb6t/CthBoUOCkCA6n50oJQ6DqnWAMyc2knkoG5mPT2RffP96j3LHyvNBRk2Y /PweuUhXF+4UaNLR6gT/xfJY00ail82fIcTBNeP+cXpMPrxX16y2W7gSzjsmREIiL5XI W668ckOdDYqPtEjxEH89Ek9RucA1RhqhbpRQ4Mb+0kVQxZXT0DPse3JPSrdyxZjraG/+ 8s6A== X-Gm-Message-State: AMCzsaVDFR3VgFxKv6LaSSaDEeCcMvOgMlQTIp6waDv1DEtOm7aa2AMQ gFKZp0FBx7OZgTVptaN/zQpfGWTfVyA= X-Google-Smtp-Source: ABhQp+SlKFWZ11wVsDJ0qGfRmbquBETd6YCo4ZCGg7WtVyanvgLdxKKqLo5QHIGVa88ONbBm4mnb1g== X-Received: by 10.28.193.76 with SMTP id r73mr3105345wmf.18.1508681712042; Sun, 22 Oct 2017 07:15:12 -0700 (PDT) Received: from localhost.localdomain ([160.161.173.60]) by smtp.gmail.com with ESMTPSA id o25sm1727321wro.49.2017.10.22.07.15.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 07:15:10 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, linux@armlinux.org.uk Cc: linux-arm-kernel@lists.infradead.org, zyw@rock-chips.com, jeffy.chen@rock-chips.com, gregory.clement@free-electrons.com, mbrugger@suse.com, matt@codeblueprint.co.uk, Ard Biesheuvel Subject: [PATCH] efi/libstub: arm: omit sorting of the UEFI memory map Date: Sun, 22 Oct 2017 15:14:57 +0100 Message-Id: <20171022141457.28769-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.11.0 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org ARM shares its EFI stub implementation with arm64, which has some special handling in the virtual remapping code to a) make sure that we can map everything even if the OS executes with 64k page size, and b) make sure that adjacent regions with the same attributes are not reordered or moved apart in memory. The latter is a workaround for a 'feature' that was shortly recommended by UEFI spec v2.5, but deprecated shortly after, due to the fact that it broke many OS installers, including non-Linux ones, and it was never widely implemented for ARM systems. Before implementing b), the arm64 code simply rounded up all regions to 64 KB granularity, but given that that results in moving adjacent regions apart, it had to be refined when b) was implemented. The adjacency check requires a sort() pass, due to the fact that the UEFI spec does not mandate any ordering, and the inclusion of the lib/sort.c code into the ARM EFI stub is causing some trouble with the decompressor build due to the fact that its EXPORT_SYMBOL() call triggers the creation of ksymtab/kcrctab sections. So let's simply do away with the adjacency check for ARM, and simply put all UEFI runtime regions together if they have the same memory attributes. This is guaranteed to work, given that ARM only supports 4 KB pages, and allows us to remove the sort() call entirely. Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/Makefile | 6 +++--- drivers/firmware/efi/libstub/arm-stub.c | 7 +++++-- 2 files changed, 8 insertions(+), 5 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Tested-by: Jeffy Chen Tested-by: Matthias Brugger Acked-by: Will Deacon Tested-by: Gregory CLEMENT Tested-by: Matthias Brugger Tested-by: Matthias Brugger Tested-by: Matthias Brugger diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index dedf9bde44db..f3e8431565ea 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -33,13 +33,14 @@ lib-y := efi-stub-helper.o gop.o secureboot.o lib-$(CONFIG_RESET_ATTACK_MITIGATION) += tpm.o # include the stub's generic dependencies from lib/ when building for ARM/arm64 -arm-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c sort.c +arm-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c +arm-deps-$(CONFIG_ARM64) += sort.c $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE $(call if_changed_rule,cc_o_c) lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o random.o \ - $(patsubst %.c,lib-%.o,$(arm-deps)) + $(patsubst %.c,lib-%.o,$(arm-deps-y)) lib-$(CONFIG_ARM) += arm32-stub.o lib-$(CONFIG_ARM64) += arm64-stub.o @@ -90,5 +91,4 @@ quiet_cmd_stubcopy = STUBCPY $@ # explicitly by the decompressor linker script. # STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub -STUBCOPY_RM-$(CONFIG_ARM) += -R ___ksymtab+sort -R ___kcrctab+sort STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c index 1cb2d1c070c3..3061e4057483 100644 --- a/drivers/firmware/efi/libstub/arm-stub.c +++ b/drivers/firmware/efi/libstub/arm-stub.c @@ -349,7 +349,9 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size, * The easiest way to find adjacent regions is to sort the memory map * before traversing it. */ - sort(memory_map, map_size / desc_size, desc_size, cmp_mem_desc, NULL); + if (IS_ENABLED(CONFIG_ARM64)) + sort(memory_map, map_size / desc_size, desc_size, cmp_mem_desc, + NULL); for (l = 0; l < map_size; l += desc_size, prev = in) { u64 paddr, size; @@ -366,7 +368,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size, * a 4k page size kernel to kexec a 64k page size kernel and * vice versa. */ - if (!regions_are_adjacent(prev, in) || + if ((IS_ENABLED(CONFIG_ARM64) && + !regions_are_adjacent(prev, in)) || !regions_have_compatible_memory_type_attrs(prev, in)) { paddr = round_down(in->phys_addr, SZ_64K);