[GIT PULL] EFI urgent fix for v4.6 queue

[GIT PULL] EFI urgent fix for v4.6 queue

[Matt Fleming]

Scott has reported another bug in the EFI mapping code which caused
page faults during SetVirtualAddressMap() because we're using 1GB
pages at the PUD level even though they may not be supported by the
cpu.

This patch is against tip/efi/core even though the bug has existed
since populate_pud() was first written in 2013. The reason I didn't
base it on tip/x86/urgent is because it would generate conflicts when
the stuff in tip/efi/core gets merged and since no one has ever
reported hitting it until now.

Let me know if you'd like me to respin this patch on top of something
else.

The following changes since commit 2ad510dc372c2caac9aada9ff6dd10e787616e1d:

  x86/efi: Only map kernel text for EFI mixed mode (2016-02-22 08:26:28 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent

for you to fetch changes up to a239b3605abff1457005b413047ddeef057a0831:

  x86/mm/pat: Fix boot crash when 1GB pages are not supported by cpu (2016-03-14 10:13:05 +0000)

----------------------------------------------------------------
 * We currently always assume that 1GB PUD pages are supported by the
   cpu which has resulted in reports of boot crashes (PF_RSVD faults)
   during SetVirtualAddressMap() when that assumption turns out to be
   false. Only use 1GB pages if supported by the cpu - Matt Fleming

----------------------------------------------------------------
Matt Fleming (1):
      x86/mm/pat: Fix boot crash when 1GB pages are not supported by cpu

 arch/x86/mm/pageattr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

[Matt Fleming]

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@talk21.com>
Tested-by: Scott Ashcroft <scott.ashcroft@talk21.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Raphael Hertzog <hertzog@debian.org>
Cc: Roger Shimizu <rogershimizu@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Signed-off-by: Matt Fleming <matt@codeblueprint.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

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

[Borislav Petkov]

On Mon, Mar 14, 2016 at 10:33:01AM +0000, Matt Fleming wrote:
> 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-qw6QB7/foO7QT0dZR+AlfA@public.gmane.org>
> Tested-by: Scott Ashcroft <scott.ashcroft-qw6QB7/foO7QT0dZR+AlfA@public.gmane.org>
> Cc: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
> Cc: Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
> Cc: Brian Gerst <brgerst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Denys Vlasenko <dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
> Cc: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Cc: Maarten Lankhorst <maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Cc: Raphael Hertzog <hertzog-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> Cc: Roger Shimizu <rogershimizu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> ---
>  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)));
>  
> --

Yap, looks ok to me as a minimal fix:

Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>

As a future cleanup, I'd carve out the sections of populate_pud() which
map the stuff up to the Gb boundary and the trailing leftover into a
helper, say, __populate_pud_chunk() or so which goes and populates with
smaller sizes, i.e., 2M and 4K and the lower levels.

This'll make populate_pud() more readable too.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.