linux-kernel - Re: /proc/pid/maps containg anonymous maps that have PROT

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: <Pine.LNX.4.64.0811051541470.19714@blonde.site>
Date:	Wed, 5 Nov 2008 16:12:57 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Török Edwin <edwintorok@...il.com>
cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: /proc/pid/maps containg anonymous maps that have PROT_NONE

On Wed, 5 Nov 2008, Török Edwin wrote:
> 
> I noticed that there are (quite large) entries in /proc/pid/maps that
> have PROT_NONE, right after an existing mapping:
> 7fffe4000000-7fffe406a000 rw-p 7fffe4000000 00:00 0
> 7fffe406a000-7fffe8000000 ---p 7fffe406a000 00:00 0
> 7ffff76d1000-7ffff76e0000 r-xp 00000000 09:03 260750                    
> /lib/libbz2.so.1.0.4
> 7ffff76e0000-7ffff78df000 ---p 0000f000 09:03 260750                    
> /lib/libbz2.so.1.0.4
> 
> I don't mind that 2Mb map, but what is 7fffe406a000-7fffe8000000 ---p ?
> (63M)
> 
> Is it coming from glibc mapping memory as PROT_NONE, and using
> mprotect/madvise to make it writable, and then
> caching the mappings for future use, rather than freeing them?

mmap PROT_NONE to reserve an arena, munmap to trim off top and bottom,
mprotect to make areas read+writable, madvise 0x4 to say MADV_DONTNEED
on some parts.  gcc?  Or the application itself (clamd) and its libs?

> I straced the program creating these, and I couldn't find anything with
> 7fffe406a000, but only before that address:
> 
> [pid 31928] mprotect(0x7fffe4000000, 135168, PROT_READ|PROT_WRITE) = 0
[snipped]
> [pid 31928] madvise(0x7fffe4021000, 4096, 0x4 /* MADV_??? */) = 0
> 
> There is an mprotect and madvise that end at 0x7fffe406a000.
> Those mprotects and madvise are coming from glibc. Its strange that I
> don't see the mmap only the mprotect, but I used strace -f.
> 
> This happens on:
> Linux debian 2.6.26-1-amd64 #1 SMP Thu Oct 9 14:16:53 UTC 2008 x86_64
> GNU/Linux
> 
> strace is here:
> http://edwintorok.googlepages.com/log2.bz2

Just before your first mprotect above there's:

[pid 31928] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 <unfinished ...>
[pid 31938] futex(0x7ffff6e489e0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 31928] <... mmap resumed> )        = 0x7fffe2bd3000

  which maps 7fffe2bd3000-7fffeabd3000; then

[pid 31928] munmap(0x7fffe2bd3000, 21155840 <unfinished ...>
[pid 31938] <... futex resumed> )       = 0
[pid 31928] <... munmap resumed> )      = 0

  which unmaps 7fffe2bd3000-7fffe4000000; and then

[pid 31928] munmap(0x7fffe8000000, 45953024) = 0

  which unmaps 7fffe8000000-7fffeabd3000.

So it's trimming off the rough edges to leave 7fffe4000000-7fffe8000000
mapped PROT_NONE, then mprotecting what it needs of that.

Why does it mmap too much then trim it down?  Perhaps it's trying to
minimize pagetable usage, perhaps it's internally convenient to base
on rounded addresses, I don't know.

But the mmap is there: just easily overlooked because of the way it
munmaps too (with strace showing hex addresses but decimal sizes).

Hugh