[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.

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

[Matt Fleming]

Folks, the following patch fixes a bug that is triggered with the new
EFI page table code sitting in tip/efi/core and queued up for the
merge window.

It turns out that we were relying on the kernel's mappings for those
regions that are marked E820_RESERVED, etc in the e820 map. The
specific example in the bug report was page zero which was always
"special" on legacy BIOS.

On EFI, legitimate code/data can be placed there and so if it's part
of the EFI memory map, we must make sure we map it into the EFI page
tables. EFI runtime drivers may need to access it.

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 c7af05d993ef60102eea6e0056de7eb5f6d4e52d:

  x86/efi: Always map boot service regions into new EFI page tables (2016-03-11 11:08:36 +0000)

----------------------------------------------------------------
 * Fix a bug triggered with the new separate EFI page table code where
   EFI boot services regions that are marked E820_RESERVED are not
   mapped into the page tables, leading to an oops during
   SetVirtualAddressMap() - Matt Fleming

----------------------------------------------------------------
Matt Fleming (1):
      x86/efi: Always map boot service regions into new EFI page tables

 arch/x86/platform/efi/quirks.c | 79 +++++++++++++++++++++++++++++++++---------
 1 file changed, 62 insertions(+), 17 deletions(-)