linux-kernel - Re: [PATCH] x86: Construct 32 bit boot time page tables in native format.

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: <47992A3B.7000607@zytor.com>
Date:	Thu, 24 Jan 2008 16:15:55 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Ian Campbell <ijc@...lion.org.uk>, Ingo Molnar <mingo@...e.hu>,
	Mika Penttilä <mika.penttila@...umbus.fi>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] x86: Construct 32 bit boot time page tables in native
 format.

Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> Yeah, I'm aware of this particular piece of Xen braindamage, and 
>> although I had some very unkind words to say about it, it mirrors what 
>> we have to do for the !PAE case anyway, so it can be sort of glossed 
>> over.
> 
> Sort of.  If Xen weren't an issue, then both cases are a matter of 
> copying a set of entries from one place in the pgd to another.
> 

No, if Xen wasn't an issue there wouldn't be anything to do for the PAE 
case at all (since the PGD is trivial.)

Copying PMDs is more or less an analogous case of the !PAE case, once 
the allocation is already done.  The allocation should be trivial 
though, since this would be a one-time thing.

> It would be easy enough to add some code on xen side to look for pmd 
> aliases when using/pinning a pagetable, and allocate'n'copy a new pmd 
> page as needed.  That way the core code can ignore the issue.

As much as I'd rather see Xen fixing this than having it continue to 
impact the kernel, I presume it will take some time to flush the broken 
hypervisors out?

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