linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "tip-bot2 for Borislav Petkov" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@suse.de>,
	Nathan Chancellor <nathan@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/urgent] x86/efi: Remove EFI PGD build time checks
Date: Sat, 06 Feb 2021 12:56:21 -0000	[thread overview]
Message-ID: <161261618116.23325.7532441736961791743.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20210107223424.4135538-1-arnd@kernel.org>

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     816ef8d7a2c4182e19bc06ab65751cb9e3951e94
Gitweb:        https://git.kernel.org/tip/816ef8d7a2c4182e19bc06ab65751cb9e3951e94
Author:        Borislav Petkov <bp@suse.de>
AuthorDate:    Fri, 05 Feb 2021 11:31:31 +01:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Sat, 06 Feb 2021 13:54:14 +01:00

x86/efi: Remove EFI PGD build time checks

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 <arnd@arndb.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: http://lkml.kernel.org/r/20210107223424.4135538-1-arnd@kernel.org
---
 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 e1e8d4e..8efd003 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);

      parent reply	other threads:[~2021-02-06 12:57 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-07 22:34 [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index Arnd Bergmann
2021-01-07 22:42 ` Nathan Chancellor
2021-01-13 17:51 ` Ard Biesheuvel
2021-01-15 18:23 ` Borislav Petkov
2021-01-15 18:32   ` Nathan Chancellor
2021-01-15 19:07     ` Borislav Petkov
2021-01-15 19:11       ` Arvind Sankar
2021-01-15 19:18         ` Borislav Petkov
2021-01-15 19:54           ` Arnd Bergmann
2021-01-15 20:12             ` Arvind Sankar
2021-01-15 20:32               ` Arvind Sankar
2021-01-15 19:07 ` Arvind Sankar
2021-01-15 20:27   ` Arvind Sankar
2021-01-16 16:34     ` Ard Biesheuvel
2021-01-18 20:24       ` Borislav Petkov
2021-01-18 21:42         ` Arvind Sankar
2021-01-20  9:33           ` Ard Biesheuvel
2021-01-20 11:44             ` Borislav Petkov
2021-02-03 18:51             ` Nathan Chancellor
2021-02-03 20:29               ` Ard Biesheuvel
2021-02-04 10:51                 ` Borislav Petkov
2021-02-04 10:59                   ` Ard Biesheuvel
2021-02-04 19:16                   ` Nathan Chancellor
2021-02-04 21:43                   ` Arvind Sankar
2021-02-04 22:13                     ` Borislav Petkov
2021-02-05  0:08                       ` Arvind Sankar
2021-02-05 11:39                         ` [PATCH] x86/efi: Remove EFI PGD build time checks Borislav Petkov
2021-02-05 11:57                           ` Ard Biesheuvel
2021-02-05 18:14                           ` Nick Desaulniers
2021-02-05 18:56                           ` Nathan Chancellor
2021-02-05 10:34               ` [PATCH] x86: efi: avoid BUILD_BUG_ON() for non-constant p4d_index Borislav Petkov
2021-02-05 18:27                 ` Nick Desaulniers
2021-02-05 18:31                   ` Nathan Chancellor
2021-01-20 11:26           ` Kirill A. Shutemov
2021-01-20 11:06   ` Kirill A. Shutemov
2021-02-06 12:56 ` tip-bot2 for Borislav Petkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=161261618116.23325.7532441736961791743.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).