From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3624CC6FA91 for ; Fri, 16 Sep 2022 10:20:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=x6ShEkQETlhQmEoG5kaWDYW80MtoiGZsSY5VZeEw0l8=; b=v4cRyINRVm2ttM WkiYwGh3Lf81e689Ca8tD7+nSsQEZgvtDnnPOTi7y9Z4z6vS9yiliRDVl+qpOgBLn0SEL85tIIacx i08LGVO+vCRIb0uYuAreAG7MG7EU/GEd3lH8cAa1SxetyJPXNyHYyNfU1B3XEx7yM68Pqq0A63Ud0 lM+Bq0e/+xRsebmE3zLQGH/6pWKbDfZzhjWeSzxUXVaXzU3XUCWzl/dNMo4QRPXJYsbYdHmUrY1eZ tizMsGfYGqCiJrGA1Fr5arhokjq/3qSd7wXROOoAwnI2k2X5+gsGhxvajPtN+KBTIvsxMpRNG+e31 LqD1QezY231SVe0DDPIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZ8R8-00C62j-Py; Fri, 16 Sep 2022 10:19:07 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZ8R4-00C60m-MD for linux-arm-kernel@lists.infradead.org; Fri, 16 Sep 2022 10:19:04 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B0069629CB; Fri, 16 Sep 2022 10:19:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5229EC433C1; Fri, 16 Sep 2022 10:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663323541; bh=ArJ0Aq/uRByH2p0oRANc/9e+rySb1VN37gb9AK9FVJs=; h=From:To:Cc:Subject:Date:From; b=mMPeKsbu6S6MdnWzvPnhv7WHA/bN5bCLuUKuYJaO/7FdncJX00DMYgg2XZPsSzFbh 8EMaYvWP8/il9pUN0zOujgMWQjPPgxccR0BeOlWhf4jtv6W+5N9fFDxeYWddNnV1N2 5zTGqWw2szXmrQOj819QfqRbD2IjlkdFoBtl2FCbX6XyEx/pbvBy5lfrXKjJyorpw6 4Bx0tFRmcNX8XqVZZ/QAFJ2sXpLuTRaheDrbs8Vk7QgoldtwXt3cE6yY3iEwX7Dvff 1PrS4RchaSRAjpmgpiemD4b2ToGCU6NiHgTX5VRPkCnROy0HyO/O/NlHCjXDhRhI9h 6ULs8T9sOJSfg== From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, probinson@gmail.com, andersson@kernel.org, catalin.marinas@arm.com, will@kernel.org, Ard Biesheuvel Subject: [PATCH] efi/libstub: arm64: avoid SetVirtualAddressMap() when possible Date: Fri, 16 Sep 2022 12:18:43 +0200 Message-Id: <20220916101843.495879-1-ardb@kernel.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1930; i=ardb@kernel.org; h=from:subject; bh=ArJ0Aq/uRByH2p0oRANc/9e+rySb1VN37gb9AK9FVJs=; b=owEB7QES/pANAwAKAcNPIjmS2Y8kAcsmYgBjJE2Cou4slodCTvcpov6C34JFi70JaD9PhOanWIgf 4MTLxeuJAbMEAAEKAB0WIQT72WJ8QGnJQhU3VynDTyI5ktmPJAUCYyRNggAKCRDDTyI5ktmPJCKeC/ 0ekQEjJgqxQ8MOatq+grhrCBtZdiKr2ORm88O4fFCt1m3pnNANNV47MMv95sgFVAIVP2nEuZ9+jSsn ROwJ/n8wJ0mPEemybS8u2NwDuU2oLdiHr3W5K09sLc9fRGGVEeT5rGvBZW9i2neu0PhFuyrXeq0lx+ pa0KDWnDbq41ItwyyTTwk6P/UPOwojKwb9sQF/wZgAfltLb5h3vMCMk9uRz1mSkw7YyJ4woqGWI2h/ dS5Hk0XO1JynK71+d7TGieQztW61kY+EoOOD2FiAHoFQkBfnrZzRUIUId+LDwNJTU02C2uFyUPf73b 5yZH/UJOkDH4ozgKxdB4MlhHF0xr4f0xBT/USKlvy1k4R37EBu1CBwq8rKonPDstkiXcO/qpzeVTnC Rt1zQmbKNRTQ8M6zWOsATPHC4TMAVcxn3BAw0Qn9qvLe2SZ5BeXDSOr48iy9ddi9m7RDLqtpH+rJzh t8FWWoMWnH3o0Gu1aAB1xPzgLqGksHUJ+tiXkAZabVh1w= X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220916_031902_836007_6CBAC540 X-CRM114-Status: GOOD ( 16.50 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd like to avoid using, if possible. For 64-bit architectures such as arm64, the user and kernel mappings are entirely disjoint, and given that we use the user region for mapping the UEFI runtime regions when running under the OS, we don't rely on SetVirtualAddressMap() in the conventional way, i.e., to permit kernel mappings of the OS to coexist with kernel region mappings of the firmware regions. This means that, in principle, we should be able to avoid SetVirtualAddressMap() altogether, and simply use the 1:1 mapping that UEFI uses at boot time. (Note that omitting SetVirtualAddressMap() is explicitly permitted by the UEFI spec). However, there is a corner case on arm64, which, if configured for 3-level paging (or 2-level paging when using 64k pages), may not be able to cover the entire range of firmware mappings (which might contain both memory and MMIO peripheral mappings). So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space is guaranteed to be of sufficient size. Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c index cd3bea25c762..4fff6c32899e 100644 --- a/drivers/firmware/efi/libstub/arm64-stub.c +++ b/drivers/firmware/efi/libstub/arm64-stub.c @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void) efi_err("This 16 KB granular kernel is not supported by your CPU\n"); return EFI_UNSUPPORTED; } + + /* + * If we have 48 bits of VA space for TTBR0 mappings, we can map the + * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is + * unnecessary. + */ + if (VA_BITS_MIN >= 48) + efi_novamap = true; + return EFI_SUCCESS; } -- 2.35.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 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 C5F2EECAAD8 for ; Fri, 16 Sep 2022 10:34:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231293AbiIPKe3 (ORCPT ); Fri, 16 Sep 2022 06:34:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231837AbiIPKd3 (ORCPT ); Fri, 16 Sep 2022 06:33:29 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A6E36394 for ; Fri, 16 Sep 2022 03:19:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6C91FB82572 for ; Fri, 16 Sep 2022 10:19:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5229EC433C1; Fri, 16 Sep 2022 10:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1663323541; bh=ArJ0Aq/uRByH2p0oRANc/9e+rySb1VN37gb9AK9FVJs=; h=From:To:Cc:Subject:Date:From; b=mMPeKsbu6S6MdnWzvPnhv7WHA/bN5bCLuUKuYJaO/7FdncJX00DMYgg2XZPsSzFbh 8EMaYvWP8/il9pUN0zOujgMWQjPPgxccR0BeOlWhf4jtv6W+5N9fFDxeYWddNnV1N2 5zTGqWw2szXmrQOj819QfqRbD2IjlkdFoBtl2FCbX6XyEx/pbvBy5lfrXKjJyorpw6 4Bx0tFRmcNX8XqVZZ/QAFJ2sXpLuTRaheDrbs8Vk7QgoldtwXt3cE6yY3iEwX7Dvff 1PrS4RchaSRAjpmgpiemD4b2ToGCU6NiHgTX5VRPkCnROy0HyO/O/NlHCjXDhRhI9h 6ULs8T9sOJSfg== From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, probinson@gmail.com, andersson@kernel.org, catalin.marinas@arm.com, will@kernel.org, Ard Biesheuvel Subject: [PATCH] efi/libstub: arm64: avoid SetVirtualAddressMap() when possible Date: Fri, 16 Sep 2022 12:18:43 +0200 Message-Id: <20220916101843.495879-1-ardb@kernel.org> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1930; i=ardb@kernel.org; h=from:subject; bh=ArJ0Aq/uRByH2p0oRANc/9e+rySb1VN37gb9AK9FVJs=; b=owEB7QES/pANAwAKAcNPIjmS2Y8kAcsmYgBjJE2Cou4slodCTvcpov6C34JFi70JaD9PhOanWIgf 4MTLxeuJAbMEAAEKAB0WIQT72WJ8QGnJQhU3VynDTyI5ktmPJAUCYyRNggAKCRDDTyI5ktmPJCKeC/ 0ekQEjJgqxQ8MOatq+grhrCBtZdiKr2ORm88O4fFCt1m3pnNANNV47MMv95sgFVAIVP2nEuZ9+jSsn ROwJ/n8wJ0mPEemybS8u2NwDuU2oLdiHr3W5K09sLc9fRGGVEeT5rGvBZW9i2neu0PhFuyrXeq0lx+ pa0KDWnDbq41ItwyyTTwk6P/UPOwojKwb9sQF/wZgAfltLb5h3vMCMk9uRz1mSkw7YyJ4woqGWI2h/ dS5Hk0XO1JynK71+d7TGieQztW61kY+EoOOD2FiAHoFQkBfnrZzRUIUId+LDwNJTU02C2uFyUPf73b 5yZH/UJOkDH4ozgKxdB4MlhHF0xr4f0xBT/USKlvy1k4R37EBu1CBwq8rKonPDstkiXcO/qpzeVTnC Rt1zQmbKNRTQ8M6zWOsATPHC4TMAVcxn3BAw0Qn9qvLe2SZ5BeXDSOr48iy9ddi9m7RDLqtpH+rJzh t8FWWoMWnH3o0Gu1aAB1xPzgLqGksHUJ+tiXkAZabVh1w= X-Developer-Key: i=ardb@kernel.org; a=openpgp; fpr=F43D03328115A198C90016883D200E9CA6329909 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd like to avoid using, if possible. For 64-bit architectures such as arm64, the user and kernel mappings are entirely disjoint, and given that we use the user region for mapping the UEFI runtime regions when running under the OS, we don't rely on SetVirtualAddressMap() in the conventional way, i.e., to permit kernel mappings of the OS to coexist with kernel region mappings of the firmware regions. This means that, in principle, we should be able to avoid SetVirtualAddressMap() altogether, and simply use the 1:1 mapping that UEFI uses at boot time. (Note that omitting SetVirtualAddressMap() is explicitly permitted by the UEFI spec). However, there is a corner case on arm64, which, if configured for 3-level paging (or 2-level paging when using 64k pages), may not be able to cover the entire range of firmware mappings (which might contain both memory and MMIO peripheral mappings). So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space is guaranteed to be of sufficient size. Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c index cd3bea25c762..4fff6c32899e 100644 --- a/drivers/firmware/efi/libstub/arm64-stub.c +++ b/drivers/firmware/efi/libstub/arm64-stub.c @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void) efi_err("This 16 KB granular kernel is not supported by your CPU\n"); return EFI_UNSUPPORTED; } + + /* + * If we have 48 bits of VA space for TTBR0 mappings, we can map the + * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is + * unnecessary. + */ + if (VA_BITS_MIN >= 48) + efi_novamap = true; + return EFI_SUCCESS; } -- 2.35.1