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]

Date:	Mon, 21 Jan 2008 21:46:36 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	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.


On Mon, 2008-01-21 at 13:38 -0800, H. Peter Anvin wrote:
> Ian Campbell wrote:
> > On Sun, 2008-01-20 at 20:30 +0200, Mika Penttilä wrote:
> >>>   
> >> You have dropped the requirement to map all of low memory (the boot 
> >> allocator is used for instance to construct physical mem mapping). 
> >> Either you should fix your INIT_MAP_BEYOND_END or make a big comment 
> >> telling us why it isn't necessary anymore to map low mem.
> > 
> > I think you are right. The patch ensures that all the initial page
> > tables themselves have mappings but won't map the additional pages
> > needed for mapping the rest of lowmem.
> > 
> > However, I think it is no longer necessary to map a whole new 4G worth
> > of page table pages because the code in kernel_physical_mapping_init now
> > extends the initial mappings rather than replacing them (see changes to
> > native_pagetable_setup_start). So now we only need to map 4G worth of
> > page tables including the initial page tables. That means we only need
> > to map a fixed set of extra pages rather than the sliding limit
> > currently used in the patch.
> > 
> 
> We still need to be able to construct those page tables, which is what 
> that stuff is about...

Yes, my initial patch was wrong. However with the patch we no longer
throw away the non-PAE initial page tables and replace them with PAE
ones, instead we augment the initial PAE page tables. This means we only
need initial mappings of 4G worth of page tables rather than 4G plus
what is needed for the non-PAE initial page tables.

I don't think I explained that at all well on either attempt...
Hopefully what I mean will be clearer in patch form -- coming in a
second...

> > I'm not convinced by the additional 16MB for CONFIG_DEBUG_PAGEALLOC --
> > we map enough pages for page tables for 4G of lowmem -- adding space for
> > an extra 16M seems pointless.
> 
> If so, adjusting the limit should be a separate patch.
> 
> Either way, I'm increasingly thinking that setting up the initial page 
> tables via an assembly loop instead of worrying about the C accessors is 
> actually cleaner (I prototyped it yesterday, although I still need the 
> rest of the machinery.)

I'm just preparing to send out a version which uses the native_* way of
doing things, its not actually as clean as I would like so I'd be
interested to see the ASM variant.

Ian.
-- 
Ian Campbell

You shall be rewarded for a dastardly deed.

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