linux-kernel - Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

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: <47F91DFD.9030508@goop.org>
Date:	Sun, 06 Apr 2008 12:01:17 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Thomas Hellström <thomas@...gstengraphics.com>
CC:	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.sourceforge.net>
Subject: Re: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

Thomas Hellström wrote:
> Hi!
>
> For a long time now, the agpgart module has been creating illegal 
> mapping aliases, since the user-space mappings of the pages in the 
> gart are usually write-combined, whereas the kernel linear mapping of 
> the same pages are uc for x86, and may even be wb for some architectures.
>
> In order to fix this, and to facilitate fast insertion and removal of 
> pages into / from the gart I'd like to disable all default kernel 
> mappings for those pages, which would in effect, make them behave as 
> highmem pages from our point of view.
>
> As prevously discussed, the x86 set_memory_xxx() interface wasn't 
> suitable for this, since it handles only a single mapping, and the 
> pages may have more than one default kernel mapping.
>
> But it turns out that there is an interface that does exactly this. 
> kernel_map_pages(). But it is only available  with 
> CONFIG_DEBUG_PAGEALLOC. I'd like to make that function exported by 
> default, but with some minor alterations as the original functions 
> does some debug checks as well, that aren't desirable for the purpose 
> mentioned above:
>
> As with highmem pages, if the driver sets up user-space mappings with 
> non-standard caching attributes, those mappings need to be killed at 
> suspend time, since the suspend code would otherwise create temporary 
> incompatible mappings.
>
> On x86 this all would probably work fine. Does kernel_map_pages() work 
> identically on other architectures? Specifically: Will it always work 
> with a 4K page granularity?

Well, not all architectures use 4k as their base page size, but 
kernel_map_pages should work at the smallest supported page size.

The disadvantage of this is that it will end up shattering any 
large-page mappings the kernel has.  This is pretty much unavoidable 
unless you can arrange to only allocate AGP pages in a physically 
distinct area away from other kernel allocations (a mechanism to do this 
might be generally useful, though I'm not sure what form it would take - 
another zone perhaps?).

    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/