RE: [Valgrind-users] SOLVED: can't run valgrind at all

[Johan E. <jo...@ek...>]

> > I suddenly realized that the kernel on the machine is patched with =
grsec
> > (www.grsecurity.net) including PaX Address Space Modification
> > Protection. This includes removal of addresses from
> > /proc/<pid>/[maps|stat] which explains valgrind crashing. After =
using
> > the chpax utility to remove this restriction from the valgrind =
binary
> > (2.1.1) or /bin/true (2.0.0) plus the program to be debugged, it =
works.
> >
> > Sorry for this, my mistake indeed. Possibly one could imagine an
> > extended error message from valgrind in case of problems reading
> > /proc/self/maps, just to help morons like me :) ("Can't read
> > /proc/self/maps, are you using some kind of security scheme which =
causes
> > this?")
>=20
> Good to hear you solved the problem.  Others have had problems with =
PaX
> and Valgrind before, but it a different way.  They complained that
> Valgrind aborted when reading the /proc/self/maps because the format =
was
> different.  (PaX introduces permissions like "R+X-", not just like
> "r-x-".)  See bug 77968 (http://bugs.kde.org/show_bug.cgi?id=3D77968).
>=20
> So it's surprising that you get this different problem -- sounds like =
your
> version of PaX doesn't have these different permission strings, which =
is
> good.  But the "removal of addresses" sounds very bad for Valgrind -- =
do
> you have more information about what happens here, and why PaX does =
it?
> If /proc/self/maps doesn't truly reflect the memory mappings, Valgrind
> will definitely be in trouble.

From the grsec kernel-config-help:

=3D=3D=3D=3D
CONFIG_GRKERNSEC_PROC_MEMMAP:                                            =

  If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files =
will
  give no information about the addresses of its mappings if
  PaX features that rely on random addresses are enabled on the task.
  If you use PaX it is greatly recommended that you say Y here as it
  closes up a hole that makes the full ASLR useless for suid binaries.
=3D=3D=3D=3D

Look at this example:

=3D=3D=3D=3D
  # cat /proc/self/maps
  00000000-00000000 r-xp 00000000 30:00 19         /bin/cat
  00000000-00000000 rw-p 00001000 30:00 19         /bin/cat
  00000000-00000000 rwxp 00000000 00:00 0
  00000000-00000000 r-xp 00000000 30:00 60854      /lib/ld-2.3.2.so
  00000000-00000000 rw-p 00014000 30:00 60854      /lib/ld-2.3.2.so
  00000000-00000000 r-xp 00000000 30:00 60531      /lib/libc-2.3.2.so
  00000000-00000000 rw-p 0012f000 30:00 60531      /lib/libc-2.3.2.so
  00000000-00000000 rw-p 00000000 00:00 0
  00000000-00000000 r--p 00000000 30:00 85818108   =
/usr/lib/locale/locale-archive
  00000000-00000000 rwxp fffff000 00:00 0

  # chpax -r /bin/cat

  # cat /proc/self/maps
  08048000-0804a000 r-xp 00000000 30:00 19         /bin/cat
  0804a000-0804b000 rw-p 00001000 30:00 19         /bin/cat
  0804b000-0804d000 rwxp 00000000 00:00 0
  40000000-40015000 r-xp 00000000 30:00 60854      /lib/ld-2.3.2.so
  40015000-40016000 rw-p 00014000 30:00 60854      /lib/ld-2.3.2.so
  4001d000-4014c000 r-xp 00000000 30:00 60531      /lib/libc-2.3.2.so
  4014c000-40151000 rw-p 0012f000 30:00 60531      /lib/libc-2.3.2.so
  40151000-40154000 rw-p 00000000 00:00 0
  40154000-40354000 r--p 00000000 30:00 85818108   =
/usr/lib/locale/locale-archive
  bfffe000-c0000000 rwxp fffff000 00:00 0
=3D=3D=3D=3D

So - the solution to run valgrind in this environment is to "chpax -r" =
the valgrind executable and the program to be run under valgrinds =
control. In version 2.0.0 valgrind is a shellscript which uses =
/bin/true, so /bin/true also has to be "chpax -r".

/Johan