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

Message-Id: <1238659491.9041.133.camel@localhost>
Date:	Thu, 02 Apr 2009 19:04:51 +1100
From:	Michael Ellerman <michael@...erman.id.au>
To:	Chris Friesen <cfriesen@...tel.com>
Cc:	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	peterz@...radead.org
Subject: Re: Resend: /proc/<pid>/maps offset output broken in 2.6.29

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 :)

> 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]
> 
> I'm at a loss to explain what's going on here.  Anyone got any ideas?

It looks like for vmas that don't have a vm_file (like the stack),
vm_pgoff is basically "internal use" - and so can be > 32 bit.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)