Re: Bug in mmap/remap_page_range?

Michael Weller (eowmob@exp-math.uni-essen.de)
Tue, 4 Jul 1995 13:58:51 +0200 (MSZ)


> From: Hans Georg Zezschwitz <redjack@science-products.com>
> Subject: Bug in mmap/remap_page_range?
> To: linux-kernel@vger.rutgers.edu
> Cc: rubini@ipvvis.UNIPV.IT

[...]
> As some might remember, I have to remap kernel-memory-space to user-space.
> After some discussions on this channel, I decided to allocate kernel-space
> via kmalloc with priority (GFP_BUFFER | GFP_DMA) and then remap it to
> user-space via opening /dev/mem as a file and mapping it to user-space.
>
> This works fine for the first page, at least using Linux 1.2.10.
>
> Any subsequent pages are *not* mapped. When debugging this, I found out

[...]

> Using Linux 1.3.6, no pages are remapped at all. A workaround for
> both versions is to tag the pages in mem_map with a MAP_PAGE_RESERVED-flag.

Keep in mind that non MAP_PAGE_RESERVED are usually subject to paging and
cannot simply be mapped via /dev/mem.

However kmalloc pages are somehow stable so one could patch
remap_page_range to handle these correctly (that is have it check for non
MAP_PAGE_RESERVED but still kernel pages). However a problem remains: Some
process may map some of the kmalloced pages via /dev/mem. The driver may
not know about and at sometime free the kmalloced pages but the map will
still remain active but now point to free, otherwise used by the kernel,
or a pageable user page. That would open worst possible races and security
problems.

A cleaner solution would be to support mmap on the device driver. This
way the device driver does always know what mem is mapped by whom. (and
it won't be THAT difficult. really...)

BTW, a similar problem was reported for /dev/kmem. Actually, did you ever try
to use /dev/kmem? I never used it myself yet. But maybe it is better used
for mapping kmalloced stuff. In theory /dev/kmem should map kernel memory
whereas /dev/mem maps physical memory (and kmalloc maps no phys memory
but virtual kernel memory, if viewed from a pure theoretical aspect (yes
I know it makes some gurantees about the physical location)), right?

Michael.

(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)