From: Matt Fleming <matt@codeblueprint.co.uk>
To: Nicolai Stange <nicstange@gmail.com>
Cc: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Mika Penttilä" <mika.penttila@nextfour.com>
Subject: Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()
Date: Fri, 23 Dec 2016 14:52:06 +0000 [thread overview]
Message-ID: <20161223145206.GC16838@codeblueprint.co.uk> (raw)
In-Reply-To: <20161222102340.2689-1-nicstange@gmail.com>
On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote:
> With commit 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid
> copying image data"), efi_bgrt_init() calls into the memblock allocator
> through efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init()
> has been called.
>
> Indeed, KASAN reports a bad read access later on in
> efi_free_boot_services():
>
> BUG: KASAN: use-after-free in efi_free_boot_services+0xae/0x24c
> at addr ffff88022de12740
> Read of size 4 by task swapper/0/0
> page:ffffea0008b78480 count:0 mapcount:-127
> mapping: (null) index:0x1 flags: 0x5fff8000000000()
> [...]
> Call Trace:
> dump_stack+0x68/0x9f
> kasan_report_error+0x4c8/0x500
> kasan_report+0x58/0x60
> __asan_load4+0x61/0x80
> efi_free_boot_services+0xae/0x24c
> start_kernel+0x527/0x562
> x86_64_start_reservations+0x24/0x26
> x86_64_start_kernel+0x157/0x17a
> start_cpu+0x5/0x14
>
> The instruction at the given address is the first read from the memmap's
> memory, i.e. the read of md->type in efi_free_boot_services().
>
> Note that the writes earlier in efi_arch_mem_reserve() don't splat because
> they're done through early_memremap()ed addresses.
>
> So, after memblock is gone, allocations should be done through the "normal"
> page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
> it from efi_arch_mem_reserve() and from efi_free_boot_services() as well.
>
> Fixes: 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
> Signed-off-by: Nicolai Stange <nicstange@gmail.com>
> ---
> arch/x86/platform/efi/quirks.c | 4 ++--
> drivers/firmware/efi/memmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/linux/efi.h | 1 +
> 3 files changed, 41 insertions(+), 2 deletions(-)
Nice catch. Could you also modify efi_fake_memmap() to use your new
efi_memmap_alloc() function for consistency (note that all
memblock_alloc()s should probably be PAGE_SIZE aligned like the
fakemem code)?
next prev parent reply other threads:[~2016-12-23 14:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 10:23 [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init() Nicolai Stange
2016-12-22 10:23 ` Nicolai Stange
2016-12-22 10:23 ` [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve " Nicolai Stange
[not found] ` <20161222102340.2689-2-nicstange-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-05 9:12 ` Dave Young
2017-01-05 9:12 ` Dave Young
2017-01-09 11:44 ` Matt Fleming
2017-01-09 11:44 ` Matt Fleming
2017-01-09 13:31 ` Mel Gorman
2017-01-09 13:31 ` Mel Gorman
2017-01-09 13:45 ` Matt Fleming
2017-01-09 13:45 ` Matt Fleming
2017-02-27 21:57 ` Matt Fleming
2017-02-27 21:57 ` Matt Fleming
2017-02-27 21:57 ` Matt Fleming
2017-01-10 0:37 ` Dave Young
2017-01-10 0:37 ` Dave Young
2017-01-10 12:51 ` Matt Fleming
2017-01-10 12:51 ` Matt Fleming
2017-01-11 8:04 ` Dave Young
2017-01-11 8:04 ` Dave Young
2016-12-23 14:52 ` Matt Fleming [this message]
2016-12-23 21:12 ` [PATCH v2 1/2] x86/efi: don't allocate memmap " Nicolai Stange
[not found] ` <878tr6jqoa.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-05 7:42 ` Ingo Molnar
2017-01-05 7:42 ` Ingo Molnar
[not found] ` <20170105074221.GA1777-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-05 9:15 ` Dave Young
2017-01-05 9:15 ` Dave Young
2017-01-05 9:39 ` Ard Biesheuvel
[not found] ` <CAKv+Gu9AabgVMQ+uZkmiJZt9shBB=j4XUccRoRJcv5+T8X7eAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-05 10:15 ` Nicolai Stange
2017-01-05 10:15 ` Nicolai Stange
[not found] ` <87inpt6ce7.fsf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-05 11:34 ` Ard Biesheuvel
2017-01-05 11:34 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-KEJ3t5kqedbcmkagyxHusuvj2whc5zLY521tRtenUBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-05 12:53 ` Nicolai Stange
2017-01-05 12:53 ` Nicolai Stange
[not found] ` <20161222102340.2689-1-nicstange-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-04 18:40 ` Dan Williams
2017-01-04 18:40 ` Dan Williams
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=20161223145206.GC16838@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=ard.biesheuvel@linaro.org \
--cc=hpa@zytor.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.penttila@nextfour.com \
--cc=mingo@redhat.com \
--cc=nicstange@gmail.com \
--cc=tglx@linutronix.de \
--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.