linux-kernel - Re: [PATCH]Fix broken VMI in 2.6.27-rc..

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: <1218145344.20178.347.camel@bodhitayantram.eng.vmware.com>
Date:	Thu, 07 Aug 2008 14:42:24 -0700
From:	Zachary Amsden <zach@...are.com>
To:	"H. Peter Anvin" <hpa@...nel.org>
Cc:	Alok Kataria <akataria@...are.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH]Fix broken VMI in 2.6.27-rc..

On Thu, 2008-08-07 at 14:34 -0700, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > That can't be done until we know the size of the hole to relocate, which
> > isn't known until we probe in the first meg of memory to find the
> > associated ROM.  It used to be the case that other things that poked
> > around with platform specific memory and checking ROM areas lived around
> > here in setup.c, so it was a nice place to put it.  With all the
> > abstraction and combination and overifdeffing going on here, that might
> > no longer be the case.
> >
> > We could move it earlier, but then we'd need another hook to call in
> > after max_low_pfn is known.
> >
> > Or we could remove the dependency on max_low_pfn and just create a
> > liberal linear to physical mapping for lomem which spans all possible
> > low memory; then it doesn't matter so much where it is called.
> >
> 
> Okay, you lost me about halfway through that... could you perhaps
> describe the problem from the beginning, exactly what you're trying to do?

A kernel compiled with VMI enabled may run on a non-VMI platform.  If
that is the case, the fixmap should not be relocated.  If however, a VMI
ROM is found, we need to hijack up to 64-MB of linear address space from
the top of memory down.  This means moving the fixmap down by the same
amount.

Right now the code is structured in such a way that it wants to know how
much physical memory there is, so it can register a mapping table for
mapping linear addresses in the lowmem area to physical addresses.  This
causes the code to depend on max_low_pfn being initialized, which
accounts for the current placement.

But it also must be called before anything that creates the fixmap,
because the same code which registers the linear address mapping also
reserves high memory above the fixmap.

My point is 1) these could be two separate calls, or 2) the lowmem
mapping table need not depend on max_low_pfn at all, it is safe to
create an extra large mapping which covers all possible lowmem instead
of the physical ram that is actually available.

Zach

--
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/