linux-kernel - [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi

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]

Message-ID: <tip-08cfb38f3ef49cfd1bba11a00401451606477d80@git.kernel.org>
Date:   Fri, 30 Nov 2018 01:58:39 -0800
From:   tip-bot for Sai Praneeth Prakhya <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     hdegoede@...hat.com, mingo@...nel.org, bp@...en8.de,
        marc.zyngier@....com, eric.snowberg@...cle.com,
        sai.praneeth.prakhya@...el.com, hpa@...or.com,
        julien.thierry@....com, arend.vanspriel@...adcom.com,
        bhsharma@...hat.com, dave.hansen@...el.com, peterz@...radead.org,
        ard.biesheuvel@...aro.org, torvalds@...ux-foundation.org,
        jonathanh@...dia.com, joe@...ches.com, matt@...eblueprint.co.uk,
        linux-kernel@...r.kernel.org, luto@...nel.org,
        zhuyifei1999@...il.com, sedat.dilek@...il.com, tglx@...utronix.de,
        natechancellor@...il.com
Subject: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions
 from efi_pgd

Commit-ID:  08cfb38f3ef49cfd1bba11a00401451606477d80
Gitweb:     https://git.kernel.org/tip/08cfb38f3ef49cfd1bba11a00401451606477d80
Author:     Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>
AuthorDate: Thu, 29 Nov 2018 18:12:24 +0100
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Fri, 30 Nov 2018 09:10:30 +0100

x86/efi: Unmap EFI boot services code/data regions from efi_pgd

efi_free_boot_services(), as the name suggests, frees EFI boot services
code/data regions but forgets to unmap these regions from efi_pgd. This
means that any code that's running in efi_pgd address space (e.g:
any EFI runtime service) would still be able to access these regions but
the contents of these regions would have long been over written by
someone else. So, it's important to unmap these regions. Hence,
introduce efi_unmap_pages() to unmap these regions from efi_pgd.

After unmapping EFI boot services code/data regions, any illegal access
by buggy firmware to these regions would result in page fault which will
be handled by EFI specific fault handler.

Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Acked-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Arend van Spriel <arend.vanspriel@...adcom.com>
Cc: Bhupesh Sharma <bhsharma@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Dave Hansen <dave.hansen@...el.com>
Cc: Eric Snowberg <eric.snowberg@...cle.com>
Cc: Hans de Goede <hdegoede@...hat.com>
Cc: Joe Perches <joe@...ches.com>
Cc: Jon Hunter <jonathanh@...dia.com>
Cc: Julien Thierry <julien.thierry@....com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Marc Zyngier <marc.zyngier@....com>
Cc: Matt Fleming <matt@...eblueprint.co.uk>
Cc: Nathan Chancellor <natechancellor@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Sedat Dilek <sedat.dilek@...il.com>
Cc: YiFei Zhu <zhuyifei1999@...il.com>
Cc: linux-efi@...r.kernel.org
Link: http://lkml.kernel.org/r/20181129171230.18699-6-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 arch/x86/platform/efi/quirks.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 95e77a667ba5..09e811b9da26 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -369,6 +369,24 @@ void __init efi_reserve_boot_services(void)
 	}
 }
 
+/*
+ * Apart from having VA mappings for EFI boot services code/data regions,
+ * (duplicate) 1:1 mappings were also created as a quirk for buggy firmware. So,
+ * unmap both 1:1 and VA mappings.
+ */
+static void __init efi_unmap_pages(efi_memory_desc_t *md)
+{
+	pgd_t *pgd = efi_mm.pgd;
+	u64 pa = md->phys_addr;
+	u64 va = md->virt_addr;
+
+	if (kernel_unmap_pages_in_pgd(pgd, pa, md->num_pages))
+		pr_err("Failed to unmap 1:1 mapping for 0x%llx\n", pa);
+
+	if (kernel_unmap_pages_in_pgd(pgd, va, md->num_pages))
+		pr_err("Failed to unmap VA mapping for 0x%llx\n", va);
+}
+
 void __init efi_free_boot_services(void)
 {
 	phys_addr_t new_phys, new_size;
@@ -393,6 +411,13 @@ void __init efi_free_boot_services(void)
 			continue;
 		}
 
+		/*
+		 * Before calling set_virtual_address_map(), EFI boot services
+		 * code/data regions were mapped as a quirk for buggy firmware.
+		 * Unmap them from efi_pgd before freeing them up.
+		 */
+		efi_unmap_pages(md);
+
 		/*
 		 * Nasty quirk: if all sub-1MB memory is used for boot
 		 * services, we can get here without having allocated the