linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <47F8DA44.3070008@tungstengraphics.com>
Date:	Sun, 06 Apr 2008 16:12:20 +0200
From:	Thomas Hellström <thomas@...gstengraphics.com>
To:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
CC:	dri-devel <dri-devel@...ts.sourceforge.net>
Subject: [RFC] Use kernel_map_pages() to avoid illegal page aliasing.

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?

Thanks,
Thomas

/*
* Enable / disable all default kernel mappings of a number of contigous 
pages.
* This is an alias for kernel_map_pages() but with debug checks removed.
*/

int kernel_default_map_pages(struct page *page, int numpages, int enable);
EXPORT_SYMBOL(kernel_default_map_pages);

/*
* Enable / disable all default kernel mappings of a number of single pages.
*/
int kernel_default_map_pagearray(struct page **pages, int numpages, int 
enable);
EXPORT_SYMBOL(kernel_default_map_pagearray);

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