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]

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/