From: Baoquan He <bhe@redhat.com>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
Kees Cook <keescook@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
"izumi.taku@jp.fujitsu.com" <izumi.taku@jp.fujitsu.com>,
Thomas Garnier <thgarnie@google.com>,
"fanc.fnst@cn.fujitsu.com" <fanc.fnst@cn.fujitsu.com>,
Junichi Nomura <j-nomura@ce.jp.nec.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"dyoung@redhat.com" <dyoung@redhat.com>
Subject: Re: [PATCH] x86/boot: check overlap between kernel and EFI_BOOT_SERVICES_*
Date: Wed, 23 Aug 2017 16:24:25 +0800 [thread overview]
Message-ID: <20170823082425.GA12178@x1> (raw)
In-Reply-To: <20170728064810.GA26208@hori1.linux.bs1.fc.nec.co.jp>
Hi Naoya,
On 07/28/17 at 06:48am, Naoya Horiguchi wrote:
> > > > So I think of adding some assertion in the patch 1/2 to detect this overlap
> > > > in extract_kernel() even for no KASLR case.
> > >
> > > EFI_BOOT_SERVICES_* memory are collected as e820 region of
> > > E820_TYPE_RAM, how can we guarantee kernel won't use them after jumping
> > > into the running kernel whether KASLR enabled or not? We can only wish
>
> Current kernels have no such check, so it's not guarantted, I think.
> And I guess that most firmwares (luckily?) avoid the overlap, and/or
> if the overlap happens, that might not cause any detectable error.
>
> > > that EFI firmware engineer don't put EFI_BOOT_SERVICES_* far from
> > sorry, typo. I meant EFI boot
> > service region need be put far from 0x1000000. Otherwise normal kernel could
> > allocate memory bottom up and stomp on them. It's embarassment caused by
> > the hardware flaw of x86 platfrom.
> > > 0x1000000 where normal kernel is loaded.
>
>
> > > > So I think of adding some assertion in the patch 1/2 to detect this overlap
> > > > in extract_kernel() even for no KASLR case.
>
> Anyway I wrote the following patch adding the assertion as a separate one.
> I'm glad if I can get your feedback or advise.
Sorry, I didn't notice your mail in this deep thread. I think it makes
sense to do something about the overlap. Maybe you can repost a patch
independently, or put it together with the patchset excluding
EFI_BOOT_SERVICES_{CODE|DATA}. Let's see what x86 maintainers and EFI
subsystem maintainers will say.
By the way, Ingo has helped to put my patchset of kernel mirror handling
related to kaslr into tip/x86/boot, you can base your
EFI_BOOT_SERVICES_{CODE|DATA} excluding patchset and repost. Maybe start
a new thread, it might not be easy to follow in a too deep thread.
THanks
Baoquan
> From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Date: Thu, 27 Jul 2017 13:19:35 +0900
> Subject: [PATCH] x86/boot: check overlap between kernel and
> EFI_BOOT_SERVICES_*
>
> Even when KASLR is turned off, kernel still could overlap with
> EFI_BOOT_SERVICES_* region, for example because of firmware memmap
> layout and/or CONFIG_PHYSICAL_START.
>
> So this patch adds an assertion that we are free from the overlap
> which is called for non-KASLR case.
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> ---
> arch/x86/boot/compressed/kaslr.c | 3 ---
> arch/x86/boot/compressed/misc.c | 56 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index a6604717d4fe..5549c80b45c2 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -721,9 +721,6 @@ void choose_random_location(unsigned long input,
>
> boot_params->hdr.loadflags |= KASLR_FLAG;
>
> - /* Prepare to add new identity pagetables on demand. */
> - initialize_identity_maps();
> -
> /* Record the various known unsafe memory ranges. */
> mem_avoid_init(input, input_size, *output);
>
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index a0838ab929f2..b23159fa159c 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -15,6 +15,8 @@
> #include "error.h"
> #include "../string.h"
> #include "../voffset.h"
> +#include <linux/efi.h>
> +#include <asm/efi.h>
>
> /*
> * WARNING!!
> @@ -169,6 +171,55 @@ void __puthex(unsigned long value)
> }
> }
>
> +#ifdef CONFIG_EFI
> +bool __init
> +efi_kernel_boot_services_overlap(unsigned long start, unsigned long size)
> +{
> + int i;
> + u32 nr_desc;
> + struct efi_info *e = &boot_params->efi_info;
> + efi_memory_desc_t *md;
> + char *signature;
> + unsigned long pmap;
> +
> + signature = (char *)&boot_params->efi_info.efi_loader_signature;
> + if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
> + strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
> + return false;
> +
> +#ifdef CONFIG_X86 /* Can't handle data above 4GB at this time */
> + if (e->efi_memmap_hi) {
> + warn("Memory map is above 4GB, EFI should be disabled.\n");
> + return false;
> + }
> + pmap = e->efi_memmap;
> +#else
> + pmap = (e->efi_memmap | ((__u64)e->efi_memmap_hi << 32));
> +#endif
> +
> + add_identity_map(pmap, e->efi_memmap_size);
> +
> + nr_desc = e->efi_memmap_size / e->efi_memdesc_size;
> + for (i = 0; i < nr_desc; i++) {
> + md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
> + if (md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT) <= start)
> + continue;
> + if (md->phys_addr >= start + size)
> + continue;
> + if (md->type == EFI_BOOT_SERVICES_CODE ||
> + md->type == EFI_BOOT_SERVICES_DATA)
> + return true;
> + }
> + return false;
> +}
> +#else
> +bool __init
> +efi_kernel_boot_services_overlap(unsigned long start, unsigned long size)
> +{
> + return false;
> +}
> +#endif
> +
> #if CONFIG_X86_NEED_RELOCS
> static void handle_relocations(void *output, unsigned long output_len,
> unsigned long virt_addr)
> @@ -372,6 +423,9 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
> debug_putaddr(output_len);
> debug_putaddr(kernel_total_size);
>
> + /* Prepare to add new identity pagetables on demand. */
> + initialize_identity_maps();
> +
> /*
> * The memory hole needed for the kernel is the larger of either
> * the entire decompressed kernel plus relocation table, or the
> @@ -402,6 +456,8 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
> if (virt_addr != LOAD_PHYSICAL_ADDR)
> error("Destination virtual address changed when not relocatable");
> #endif
> + if (efi_kernel_boot_services_overlap((unsigned long)output, output_len))
> + error("Kernel overlaps EFI_BOOT_SERVICES area");
>
> debug_putstr("\nDecompressing Linux... ");
> __decompress(input_data, input_len, NULL, NULL, output, output_len,
> --
> 2.7.4
>
>
next prev parent reply other threads:[~2017-08-23 8:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-06 8:31 [PATCH] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice Naoya Horiguchi
2017-07-06 9:13 ` Chao Fan
2017-07-06 9:22 ` Naoya Horiguchi
2017-07-06 9:36 ` Chao Fan
2017-07-06 9:18 ` Baoquan He
2017-07-06 9:36 ` Naoya Horiguchi
2017-07-06 10:04 ` Chao Fan
2017-07-06 10:20 ` Chao Fan
2017-07-06 14:57 ` Matt Fleming
2017-07-07 3:07 ` Baoquan He
2017-07-07 6:11 ` Naoya Horiguchi
2017-07-07 10:58 ` Matt Fleming
2017-07-10 5:47 ` Naoya Horiguchi
2017-07-10 5:51 ` [PATCH v3 1/2] " Naoya Horiguchi
2017-07-24 13:17 ` Matt Fleming
2017-07-25 6:17 ` Naoya Horiguchi
2017-07-10 5:51 ` [PATCH v3 2/2] x86/efi: clean up dead code around efi_reserve_boot_services() Naoya Horiguchi
2017-07-24 13:20 ` Matt Fleming
2017-07-26 0:12 ` Naoya Horiguchi
2017-07-26 1:13 ` Baoquan He
2017-07-26 1:34 ` Baoquan He
2017-07-28 6:48 ` [PATCH] x86/boot: check overlap between kernel and EFI_BOOT_SERVICES_* Naoya Horiguchi
2017-07-29 10:04 ` kbuild test robot
2017-07-29 13:01 ` [RFC PATCH] x86/boot: efi_kernel_boot_services_overlap can be static kbuild test robot
2017-07-29 13:01 ` [PATCH] x86/boot: check overlap between kernel and EFI_BOOT_SERVICES_* kbuild test robot
2017-08-23 8:24 ` Baoquan He [this message]
2017-07-07 10:56 ` [PATCH] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice Matt Fleming
2017-07-09 10:44 ` Baoquan He
2017-07-09 14:27 ` Baoquan He
2017-07-07 7:22 ` [PATCH v2 1/2] " Naoya Horiguchi
2017-07-07 7:22 ` [PATCH v2 2/2] x86/efi: clean up dead code around efi_reserve_boot_services() Naoya Horiguchi
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=20170823082425.GA12178@x1 \
--to=bhe@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=dyoung@redhat.com \
--cc=fanc.fnst@cn.fujitsu.com \
--cc=hpa@zytor.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.