linux-kernel - Re: [PATCH] x86: create array based interface to change page attribute

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: <47F391BD.1060306@linux.intel.com>
Date:	Wed, 02 Apr 2008 07:01:33 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Thomas Hellström <thomas@...gstengraphics.com>
CC:	Andi Kleen <andi@...stfloor.org>, Dave Airlie <airlied@...hat.com>,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com
Subject: Re: [PATCH] x86: create array based interface to change page attribute

Thomas Hellström wrote:
> Arjan van de Ven wrote:
>> Thomas Hellström wrote:
>>
>>> But what mappings are there,  immediately after alloc_page(), that 
>>> set_memory_np won't catch? 
>>
>> For example on x86 64bit, the kernel text is mapped (to allow 
>> relocatable) in another
>> space as well.. and to allow 2Mb tlbs for this, that second mapping is 
>> bigger than it strictly needs to be.
>> So your alloc_page() could get a page from the free pool that comes 
>> from the pages that have a second mapping
>> due to this rounding.
>> (and more fun, since it's close to frequently accessed memory, the hw 
>> prefetchers may actually just decide to pull
>> such pages into the cache preemptively)
>>
>>
>>> Drivers relying on set_memory_uc touching all mappings the driver 
>>> hasn't set up itself must then have the same problem and needs to be 
>>> fixed; referring in particular to agpgart for which driver the old 
>>> CPA functionality was once created, IIRC.
>>
>> "uc" is different than "np"; for "uc" the implementation, if your cpu 
>> needs this, will fix
>> up the shadow text mappings already today.
>>
>> for "present" this doesn't make sense, since no cpu needs this.
> If this is the checkalias() thingy in x86/pageattr.c, it looks like it 
> doesn't handle np different from the uc case. It does obviously skip NX 
> bit manipulations, though.
> 
> Anyway, a more direct question: If we were to fix whatever's missing for 
> the code to fixup the x86-64 shadow text mapping, would you be opposing 
> this way 

I do really oppose set_memory_np/p to work on anything but the mapping it is handled.
that _uc and co touch other mappings is a cpu specific property and an implementation
detail to the API. If/When CPUs exist that don't have issues with aliases, those CPUs
will not change the other mappings.

 > to fix the long standing uc/wc aliasing issue, provided we

I'm not opposed to a real fix. I am opposed to a bad hack.

> don't hit any other problems, like clflush() refusing to run on an NP page?

yes clflush doesn't work on not present pages ;)
--
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/