Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1873101pxb; Fri, 5 Feb 2021 03:44:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJykVj66wAK9GLuUeecdZEEYryWa+CfFZSu91CTUHhNrDS/Tjd0T+f1kuAoP5FduNym/yNYV X-Received: by 2002:a17:907:35d1:: with SMTP id ap17mr3815386ejc.79.1612525447070; Fri, 05 Feb 2021 03:44:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612525447; cv=none; d=google.com; s=arc-20160816; b=A5z00HcZh/UxjHnLVKBaHVA9aH7ooX2nuIMENXHTmXzvHBEaODOSOKuLJGboU7U+8r 1eaD0pLziKDc3u7YLGqyHPylEPHsHsfIMuwyxzy5W5phMyoLQqw8loZi1u0LPqMxF/+I TOonvmU6fWsbcQ4mR0J6uHKeuPjTCSfgvbMC5XmrQ5J4eR98xm8/6ofGxwXrcPdQf1Cs 0NtTSZL3U2fKuhvLU4VJokVhNfxF6hY0blW6wqstN0P9IL12uOekygyl9Nho4c+vkQCR mHyJCIxXNgUhW5ucVDndKrHvpyDNUlv/QeE2CoRtsI9o5N7Mx0MV6M8FylHA8PGDdfTj Bctw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kSeV9Aw1SUgfBE9TGeggqP2AzhIJpeYLs22VEjg0WgM=; b=Kg+eT2YBrsLpc49HxjV04Crl3hUf2PV1ADI9j3br3P/VN6TCikMXw9E1J/XtuqmVC9 2KI9WdeQ/JXihJJVlk6Hj1mgKTymhAWBpKK9jBCOatM52bAZDLSyC1EbEl4w6ASzRsaN cf4cs1te7At97xgSbnAk/iYREIXxiga1xjeW6ohhYwggWyWoz99iHqREAPs4EKJA6YB2 CJk0w9laNiMiqrF6mxvRaLMflLjUFYoDUfOF+BoH3lAXI6ThnPDTMxk6CT3C4WA5WZgf vUtjaTWVPxLO9KCxoPD4wD2dEUZhWCpGnVcdsv8i0onfwreSdg9jCEKzNiyoFHa2H8J0 FnYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=axZqZvEb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g1si4996322ejz.557.2021.02.05.03.43.41; Fri, 05 Feb 2021 03:44:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=axZqZvEb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230466AbhBELmY (ORCPT + 99 others); Fri, 5 Feb 2021 06:42:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231596AbhBELkP (ORCPT ); Fri, 5 Feb 2021 06:40:15 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31702C06178A; Fri, 5 Feb 2021 03:39:35 -0800 (PST) Received: from zn.tnic (p200300ec2f0bad00ff9d6d5b91facfca.dip0.t-ipconnect.de [IPv6:2003:ec:2f0b:ad00:ff9d:6d5b:91fa:cfca]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id A04C61EC0529; Fri, 5 Feb 2021 12:39:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1612525172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=kSeV9Aw1SUgfBE9TGeggqP2AzhIJpeYLs22VEjg0WgM=; b=axZqZvEbxIyZnWcJCvXziG6yzgM4d9zxFHfAbAYaR7DRqo9I0ybVRwTUiQy1l43c0H9B6G 1++KjwNW9svMGd1+mkh5QNROR7WOA8w5pKptRRYve+X6EvsR92tVrNTm7dIXrF2c97zYvh BwTxjcwVFD3svDBi0vKrwhHNmH2ei3c= Date: Fri, 5 Feb 2021 12:39:30 +0100 From: Borislav Petkov To: Arvind Sankar , Ard Biesheuvel , Nathan Chancellor Cc: Arnd Bergmann , Thomas Gleixner , Ingo Molnar , X86 ML , Nathan Chancellor , Nick Desaulniers , Arnd Bergmann , Darren Hart , Andy Shevchenko , "H. Peter Anvin" , linux-efi , platform-driver-x86@vger.kernel.org, Linux Kernel Mailing List , clang-built-linux , "Kirill A. Shutemov" Subject: [PATCH] x86/efi: Remove EFI PGD build time checks Message-ID: <20210205113930.GD17488@zn.tnic> References: <20210118202409.GG30090@zn.tnic> <20210203185148.GA1711888@localhost> <20210204105155.GA32255@zn.tnic> <20210204221318.GI32255@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Borislav Petkov With CONFIG_X86_5LEVEL, CONFIG_UBSAN and CONFIG_UBSAN_UNSIGNED_OVERFLOW enabled, clang fails the build with x86_64-linux-ld: arch/x86/platform/efi/efi_64.o: in function `efi_sync_low_kernel_mappings': efi_64.c:(.text+0x22c): undefined reference to `__compiletime_assert_354' which happens due to -fsanitize=unsigned-integer-overflow being enabled: -fsanitize=unsigned-integer-overflow: Unsigned integer overflow, where the result of an unsigned integer computation cannot be represented in its type. Unlike signed integer overflow, this is not undefined behavior, but it is often unintentional. This sanitizer does not check for lossy implicit conversions performed before such a computation (see -fsanitize=implicit-conversion). and that fires when the (intentional) EFI_VA_START/END defines overflow an unsigned long, leading to the assertion expressions not getting optimized away (on GCC they do)... However, those checks are superfluous: the runtime services mapping code already makes sure the ranges don't overshoot EFI_VA_END as the EFI mapping range is hardcoded. On each runtime services call, it is switched to the EFI-specific PGD and even if mappings manage to escape that last PGD, this won't remain unnoticed for long. So rip them out. See https://github.com/ClangBuiltLinux/linux/issues/256 for more info. Reported-by: Arnd Bergmann Link: http://lkml.kernel.org/r/20210107223424.4135538-1-arnd@kernel.org Signed-off-by: Borislav Petkov --- arch/x86/platform/efi/efi_64.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c index e1e8d4e3a213..8efd003540ca 100644 --- a/arch/x86/platform/efi/efi_64.c +++ b/arch/x86/platform/efi/efi_64.c @@ -115,31 +115,12 @@ void efi_sync_low_kernel_mappings(void) pud_t *pud_k, *pud_efi; pgd_t *efi_pgd = efi_mm.pgd; - /* - * We can share all PGD entries apart from the one entry that - * covers the EFI runtime mapping space. - * - * Make sure the EFI runtime region mappings are guaranteed to - * only span a single PGD entry and that the entry also maps - * other important kernel regions. - */ - MAYBE_BUILD_BUG_ON(pgd_index(EFI_VA_END) != pgd_index(MODULES_END)); - MAYBE_BUILD_BUG_ON((EFI_VA_START & PGDIR_MASK) != - (EFI_VA_END & PGDIR_MASK)); - pgd_efi = efi_pgd + pgd_index(PAGE_OFFSET); pgd_k = pgd_offset_k(PAGE_OFFSET); num_entries = pgd_index(EFI_VA_END) - pgd_index(PAGE_OFFSET); memcpy(pgd_efi, pgd_k, sizeof(pgd_t) * num_entries); - /* - * As with PGDs, we share all P4D entries apart from the one entry - * that covers the EFI runtime mapping space. - */ - BUILD_BUG_ON(p4d_index(EFI_VA_END) != p4d_index(MODULES_END)); - BUILD_BUG_ON((EFI_VA_START & P4D_MASK) != (EFI_VA_END & P4D_MASK)); - pgd_efi = efi_pgd + pgd_index(EFI_VA_END); pgd_k = pgd_offset_k(EFI_VA_END); p4d_efi = p4d_offset(pgd_efi, 0); -- 2.29.2 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette