linux-kernel - Re: [patch 3/7] x86, cpa: make the kernel physical mapping initialization a two pass sequence

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 07 Oct 2008 14:33:32 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
CC:	"mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	yinghai@...nel.org
Subject: Re: [patch 3/7] x86, cpa: make the kernel physical mapping initialization
 a two pass sequence

Suresh Siddha wrote:
> On Tue, Oct 07, 2008 at 08:28:08AM -0700, Jeremy Fitzhardinge wrote:
>   
>> Well, that's OK.  We just need to preserve the original page permissions
>> when fragmenting the large mappings.  (This isn't a case that affects
>> Xen, because it will already be 4k mappings.)
>>     
>
> Jeremy, Can you please check if the appended patch fixes your issue and Ack
> it? Test booted on three different 64bit platforms with and without
> DEBUG_PAGEALLOC.
>   

Will do.

>> Great.  Also, do you think you'll have a chance to look at unifying the
>> 32 and 64 bit code (where 32 uses the 64-bit version)?
>>     
>
> 32bit can't use the 64-bit version. 64bit uses large pages in the
> static mapping setup by head_64.S while the 32bit uses small mappings.
>   

The 64-bit code would obviously need a little bit of modification to 
make it work.

I don't see why 4k vs 2M initial mappings makes a difference.  32-bit 
dynamically sets up a pagetable in head.S.  The physical mapping setup 
can replace those mappings with large pages if it wants to.

Functionally both pieces of code are doing the same thing, and there's 
no reason why they couldn't be unified.

> I am also not sure why the Xen 32bit didn't break. With or with out may
> recent changes, 32bit kernel is always doing set_pte() and doesn't seem
> to care about the previous mappings. So what is special with 32bit xen
> that doesn't cause this failure. Thanks.
>   

I have a fairly sleazy hack in 32-bit Xen which means that set_pte 
doesn't override the page permissions when doing the physical mapping 
setup.  It's something I'd like to get rid of.

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