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: <489B7DFE.5010402@kernel.org>
Date:	Thu, 07 Aug 2008 15:58:06 -0700
From:	"H. Peter Anvin" <hpa@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Zachary Amsden <zach@...are.com>,
	Alok Kataria <akataria@...are.com>,
	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..

Linus Torvalds wrote:
> 
> On Thu, 7 Aug 2008, H. Peter Anvin wrote:
>> The only way I can see around that, though, is to move the 1:1 mapping base up
>> by 2/4 MB (for PAE/no PAE, respectively) and put the fixmap area there.  Kind
>> of sucks, but would be doable.
> 
> So if the address isn't fixed, you'll end up with an indirect pointer, and 
> it would likely be much better to just use a fixed direct pointer that is 
> not at the top.
> 
> And anything that is within the top 31 bits of the address space should 
> generate the same good code, since the fixed offset is always going to be 
> a 32-bit thing anyway. So moving the FIXMAP area down by 4MB sounds like a 
> fine thing to do with no real downside, if it then means that we don't 
> need to move the FIXMAP area at all.
> 
> Hmm? Am I missing something?

Just moving it down by 4 MB doesn't help, since the VMI guys want as 
much as 64 MB, which is half the standard vmalloc area and hence too 
much address space lost.  We can't put it at the bottom of the vmalloc 
area, since that boundary is not fixed, either.

The one remaining fixed boundary in the machine is the kernel-userspace 
boundary.  Hence moving the 1:1 area up by one PDE unit and sticking the 
fixmap area in that region.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ