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: <20120823201224.GA24203@phenom.dumpdata.com>
Date:	Thu, 23 Aug 2012 16:12:25 -0400
From:	Konrad Rzeszutek Wilk <konrad@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jacob Shin <jacob.shin@....com>, 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
> >
> >And looking into that scenario, the early boot code seems to allocates
> >space for fixmap right under initial max_pfn_mapped, which is no longer
> >direct mapped with my patch, and that seems to cause problems for later
> >APIC code that initializes APIC base address into the fixmap area.
> >
> >So I guess to address your concern, we need to go back to V2 and try to
> >resolve the fixmap problem with user supplied memory map that reserves
> >memory below initial max_pfn_mapped ?
> >
> 
> Okay... I think I need to grok that a bit better.  For memory
> allocations, we probably should just use brk allocations, for
> virtual space allocations it is called the fixmap for a reason (even
> though the Xen people managed to break that on 32 bits, sigh!)

Can you rope me in on that? Was that added ooh years ago ?
> 
> I guess I need to go back and look at David's bug report...
> 
> 	-hpa
> 
> 
> -- 
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
> 
> --
> 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/
> 
--
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/