linux-kernel - [PATCH] x86/mm/pat: Fix boot crash when 1GB pages are not supported by cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Mar 2016 10:33:01 +0000
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H . Peter Anvin" <hpa@...or.com>
Cc:	Matt Fleming <matt@...eblueprint.co.uk>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	Ben Hutchings <ben@...adent.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Brian Gerst <brgerst@...il.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Raphael Hertzog <hertzog@...ian.org>,
	Roger Shimizu <rogershimizu@...il.com>,
	Scott Ashcroft <scott.ashcroft@...k21.com>
Subject: [PATCH] x86/mm/pat: Fix boot crash when 1GB pages are not supported by cpu

Scott reports that with the new separate EFI page tables he's seeing
the following error on boot, caused by setting reserved bits in the
page table structures (fault code is PF_RSVD | PF_PROT),

  swapper/0: Corrupted page table at address 17b102020
  PGD 17b0e5063 PUD 1400000e3
  Bad pagetable: 0009 [#1] SMP

On first inspection the PUD is using a 1GB page size (_PAGE_PSE) and
looks fine but that's only true if support for 1GB PUD pages
("pdpe1gb") is present in the cpu.

Scott's Intel Celeron N2820 does not have that feature and so the
_PAGE_PSE bit is reserved. Fix this issue by making the 1GB mapping
code in conditional on "cpu_has_gbpages".

This issue didn't come up in the past because the required mapping for
the faulting address (0x17b102020) will already have been setup by the
kernel in early boot before we got to efi_map_regions(), but we no
longer use the standard kernel page tables during EFI calls.

Reported-by: Scott Ashcroft <scott.ashcroft@...k21.com>
Tested-by: Scott Ashcroft <scott.ashcroft@...k21.com>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Ben Hutchings <ben@...adent.org.uk>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Brian Gerst <brgerst@...il.com>
Cc: Denys Vlasenko <dvlasenk@...hat.com>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Cc: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Raphael Hertzog <hertzog@...ian.org>
Cc: Roger Shimizu <rogershimizu@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-efi@...r.kernel.org
Signed-off-by: Matt Fleming <matt@...eblueprint.co.uk>
---
 arch/x86/mm/pageattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 14c38ae80409..fcf8e290740a 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1055,7 +1055,7 @@ static int populate_pud(struct cpa_data *cpa, unsigned long start, pgd_t *pgd,
 	/*
 	 * Map everything starting from the Gb boundary, possibly with 1G pages
 	 */
-	while (end - start >= PUD_SIZE) {
+	while (cpu_has_gbpages && end - start >= PUD_SIZE) {
 		set_pud(pud, __pud(cpa->pfn << PAGE_SHIFT | _PAGE_PSE |
 				   massage_pgprot(pud_pgprot)));
 
-- 
2.6.2