From: Borislav Petkov <bp@alien8.de>
To: Linux EFI <linux-efi@vger.kernel.org>, X86 ML <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Cc: Borislav Petkov <bp@suse.de>,
Matt Fleming <matt@console-pimps.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
"H. Peter Anvin" <hpa@zytor.com>, Dave Young <dyoung@redhat.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Vivek Goyal <vgoyal@redhat.com>, Toshi Kani <toshi.kani@hp.com>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH 3/3] efi: Make efi virtual runtime map passing more robust
Date: Tue, 17 Dec 2013 00:36:37 +0100 [thread overview]
Message-ID: <1387236997-26975-4-git-send-email-bp@alien8.de> (raw)
In-Reply-To: <1387236997-26975-1-git-send-email-bp@alien8.de>
From: Borislav Petkov <bp@suse.de>
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of resizing
the memmap we're doing did allocate from such physical addresses which
were not mapped anymore and boom:
http://lkml.kernel.org/r/1386806463.1791.295.camel@misato.fc.hp.com
One way to take care of that issue is to reimplement the krealloc thing
but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
and when we deplete that memory (shouldn't happen all that often but you
know firmware) we realloc the next power-of-two pages.
Having the pages, it is much more handy and easy to map them into the
EFI page table with the already existing mapping code which we're using
for building the virtual mappings.
And, it doesn't matter all that much how much pages we've used as we're
freeing them right after they've fulfilled their purpose at the end of
the function anyway.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
---
arch/x86/platform/efi/efi.c | 57 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 51d6285701e9..39c52cc9b63a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -112,7 +112,6 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param("efi_no_storage_paranoia", setup_storage_paranoia);
-
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
unsigned long flags;
@@ -775,6 +774,27 @@ void __init old_map_region(efi_memory_desc_t *md)
(unsigned long long)md->phys_addr);
}
+static void *realloc_pages(void *old_memmap, int old_shift)
+{
+ void *ret;
+
+ ret = (void *)__get_free_pages(GFP_KERNEL, old_shift + 1);
+ if (!ret)
+ goto out;
+
+ /*
+ * A first-time allocation doesn't have anything to copy.
+ */
+ if (!old_memmap)
+ return ret;
+
+ memcpy(ret, old_memmap, PAGE_SIZE << old_shift);
+
+out:
+ __free_pages(old_memmap, old_shift);
+ return ret;
+}
+
/*
* This function will switch the EFI runtime services to virtual mode.
* Essentially, we look through the EFI memmap and map every region that
@@ -794,12 +814,13 @@ void __init old_map_region(efi_memory_desc_t *md)
*/
void __init efi_enter_virtual_mode(void)
{
+ pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
+ unsigned long size, new_memmap_left = 0;
efi_memory_desc_t *md, *prev_md = NULL;
+ int count = 0, new_memmap_shift = 0;
void *p, *new_memmap = NULL;
- unsigned long size;
efi_status_t status;
u64 end, systab;
- int count = 0;
efi.systab = NULL;
@@ -862,14 +883,19 @@ void __init efi_enter_virtual_mode(void)
efi.systab = (efi_system_table_t *) (unsigned long) systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
- if (!new_memmap)
- goto err_out;
+ if (new_memmap_left < memmap.desc_size) {
+ new_memmap = realloc_pages(new_memmap, new_memmap_shift);
+ if (!new_memmap)
+ goto err_out;
+
+ new_memmap_shift++;
+ new_memmap_left += PAGE_SIZE << new_memmap_shift;
+ }
memcpy(new_memmap + (count * memmap.desc_size), md,
memmap.desc_size);
+
+ new_memmap_left -= memmap.desc_size;
count++;
}
@@ -880,6 +906,19 @@ void __init efi_enter_virtual_mode(void)
efi_dump_pagetable();
+ /*
+ * It can happen that the physical address of new_memmap lands in memory
+ * which is not mapped in the EFI page table. Therefore we need to go
+ * and ident-map those pages containing the map before calling
+ * phys_efi_set_virtual_address_map().
+ */
+ if (kernel_map_pages_in_pgd(pgd, __pa(new_memmap), __pa(new_memmap),
+ 1 << new_memmap_shift, _PAGE_NX)) {
+ pr_err("Error ident-mapping new memmap (0x%lx)!\n",
+ __pa(new_memmap));
+ goto err_out;
+ }
+
status = phys_efi_set_virtual_address_map(
memmap.desc_size * count,
memmap.desc_size,
@@ -916,7 +955,7 @@ void __init efi_enter_virtual_mode(void)
if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
runtime_code_page_mkexec();
- kfree(new_memmap);
+ __free_pages(new_memmap, new_memmap_shift);
/* clean DUMMY object */
efi.set_variable(efi_dummy_name, &EFI_DUMMY_GUID,
--
1.8.4
next prev parent reply other threads:[~2013-12-16 23:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 23:36 [PATCH 0/3] EFI memmap fix Borislav Petkov
2013-12-16 23:36 ` [PATCH 1/3] x86, ptdump: Add the functionality to dump an arbitrary pagetable Borislav Petkov
2013-12-16 23:36 ` Borislav Petkov [this message]
[not found] ` <1387236997-26975-4-git-send-email-bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
2013-12-17 11:23 ` [PATCH 3/3] efi: Make efi virtual runtime map passing more robust Borislav Petkov
2013-12-17 12:10 ` Matt Fleming
2013-12-17 13:40 ` Borislav Petkov
2013-12-17 13:51 ` Matt Fleming
[not found] ` <20131217135156.GC3145-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2013-12-17 14:28 ` Borislav Petkov
2013-12-18 9:07 ` Dave Young
[not found] ` <20131218090757.GA15594-je1gSBvt1TcFLmT5oZ11vB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
2013-12-18 11:42 ` Borislav Petkov
[not found] ` <1387236997-26975-1-git-send-email-bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>
2013-12-16 23:36 ` [PATCH 2/3] efi: Dump the EFI page table Borislav Petkov
2013-12-17 1:11 ` [PATCH 0/3] EFI memmap fix Toshi Kani
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=1387236997-26975-4-git-send-email-bp@alien8.de \
--to=bp@alien8.de \
--cc=James.Bottomley@HansenPartnership.com \
--cc=arjan@linux.intel.com \
--cc=bp@suse.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=mjg59@srcf.ucam.org \
--cc=toshi.kani@hp.com \
--cc=vgoyal@redhat.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).