linux-kernel - Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29

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]

Date:	Thu, 02 Apr 2009 11:53:13 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Hugh Dickins <hugh@...itas.com>
CC:	Michael Ellerman <michael@...erman.id.au>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	peterz@...radead.org, akpm@...ux-foundation.org
Subject: Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29

Hugh Dickins wrote:
> On Thu, 2 Apr 2009, Michael Ellerman wrote:
>> On Wed, 2009-04-01 at 17:18 -0600, Chris Friesen wrote:
>>> Resending due to lack of response to original post.
>> Hi Chris,
>>
>> You'll probably get a more useful response on lkml. You CC'ed
>> linux-kernel-owner originally :)
> 
> Thanks.

Thanks from me too.  (Oops.)

>>> I was validating some code dealing with /proc/<pid>/maps on 2.6.29 and 
>>> was surprised when it failed.  It turns out that at least on my ppc64 G5 
>>> machine the offset value for the last entry is strange--it shows up as a 
>>> 64-bit value even though the process itself is only 32-bit.
>>>
>>> This behaviour also shows up in 2.6.25, but doesn't in 2.6.14.  I 
>>> haven't yet tested anything else in between.
>>>
>>> [cfriesen@...alhost cfriesen]$ cat /proc/self/maps
>>> 00100000-00103000 r-xp 00100000 00:00 0         [vdso]
>>> 0fe70000-0ffbf000 r-xp 00000000 08:03 4312393   /lib/tls/libc-2.3.3.so
>>> 0ffbf000-0ffc0000 ---p 0014f000 08:03 4312393   /lib/tls/libc-2.3.3.so
>>> 0ffc0000-0ffc2000 r--p 00150000 08:03 4312393   /lib/tls/libc-2.3.3.so
>>> 0ffc2000-0ffc6000 rwxp 00152000 08:03 4312393   /lib/tls/libc-2.3.3.so
>>> 0ffc6000-0ffc8000 rwxp 0ffc6000 00:00 0
>>> 0ffd0000-0ffec000 r-xp 00000000 08:03 4309011   /lib/ld-2.3.3.so
>>> 0fff0000-0fff1000 r--p 00020000 08:03 4309011   /lib/ld-2.3.3.so
>>> 0fff1000-0fff2000 rwxp 00021000 08:03 4309011   /lib/ld-2.3.3.so
>>> 10000000-10004000 r-xp 00000000 08:03 917536    /bin/cat
>>> 10013000-10015000 rwxp 00003000 08:03 917536    /bin/cat
>>> 10015000-10036000 rwxp 10015000 00:00 0         [heap]
>>> f7deb000-f7feb000 r--p 00000000 08:03 2560322 
>>> /usr/lib/locale/locale-archive
>>> f7feb000-f7fec000 rw-p f7feb000 00:00 0
>>> ffe6d000-ffe82000 rw-p ffffffeb000 00:00 0      [stack]

> Chris isn't the first to be concerned by that: there's a patch in
> -mm which just shows 0 instead of anon vm_pgoff in /proc/<pid>/maps
> output.  That patch is on akpm's list for 2.6.30 merge, but I think
> hasn't gone to Linus yet: expect it in a later batch.

Alternately, what about just making the offset for the stack match the 
starting address of the VMA?  That way it would look the same as other 
anonymous areas, and as a bonus would look the same as previous 
releases.  Arguably, /proc/<pid>/maps should count as userspace-visible API.

Chris

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