linux-kernel - Re: [PATCH 3/4] x86: Only direct map addresses that are marked as E820

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: <20120823223514.GA6502@jshin-Toonie>
Date:	Thu, 23 Aug 2012 17:35:14 -0500
From:	Jacob Shin <jacob.shin@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	X86-ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Tejun Heo <tj@...nel.org>,
	Borislav Petkov <borislav.petkov@....com>,
	Dave Young <dyoung@...hat.com>,
	Chao Wang <chaowang@...hat.com>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 3/4] x86: Only direct map addresses that are marked as
 E820_RAM

On Thu, Aug 23, 2012 at 08:39:10AM -0700, H. Peter Anvin wrote:
> On 08/23/2012 07:50 AM, Jacob Shin wrote:
> >>
> >>I have one concern with this, which is that it leaves in place mapping
> >>below the initial max_pfn_mapped.  Although that neatly resolves the
> >>legacy area (0-1 MiB) issues, it really isn't right above the 1 MiB
> >>point.  Any way I could get you to seek out and unmap any such ranges?
> >>We have already seen some Dell machines which put memory holes in low
> >>RAM, and perhaps there are still some machines out there with an I/O
> >>hole at 15 MiB.
> >
> >So I believe in V2 of the patchset this was done, however, Dave Young
> >from redhat reported that it broke their KVM guest with a user supplied
> >memory map that looked like this:
> >
> >>>[    0.000000] e820: user-defined physical RAM map:
> >>>[    0.000000] user: [mem 0x0000000000010000-0x000000000009dbff] usable
> >>>[    0.000000] user: [mem 0x0000000024000000-0x0000000033f6bfff] usable
> >

I looked into this a bit more, and I think what's happening is that this
user defined memory map leaves out the region where the kernel is loaded on
to during the boot process. The kernel and the direct mapped page tables up
to initial max_pfn_mapped reside somwhere under 512M (KERNEL_IMAGE_SIZE),
I guess it depends on how big your uncompressed kernel is.

And at the first attempt to set_fixmap_nocache(FIX_APIC_BASE, address) in
arch/x86/apic/apic.c: register_lapic_address runs into badness because the
memory region where the initial page tables live is no longer mapped
because of the above user supplied memory map.

So I guess there is a disconnect between really early code that seems to
rely on the boot loader as to where in physical memory it resides and its
initial page tables live, and the later memory initialization code where
it looks at the E820 (and here user can interject their own memory map
using the command line arguments)

Not really sure how to handle this case .. any advice?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/