valgrind partially broken by current hardy-proposed kernel?

[Ben Collins]

On Mon, 2008-06-02 at 09:56 -0700, Kees Cook wrote:
> Hi Colin,
> 
> On Mon, Jun 02, 2008 at 01:09:44PM +0100, Colin Watson wrote:
> > I'm getting this rather strange effect with the -17.31 kernel:
> > 
> >   <cjwatson at sarantium ~/src/debian/openssh/trunk/openssh>$ valgrind build-deb/ssh-add -l
> >   valgrind: mmap(0x0, 90112) failed in UME with error 13 (Permission denied).
> > 
> > [snip]
> > My best guess is that this is due to this commit:
> > 
> > commit 893f802872c3e3c6e4bb40c3be4845784b81b934
> > Author: Kees Cook <kees.cook at canonical.com>
> > Date:   Tue Apr 8 13:51:05 2008 -0700
> > 
> >     UBUNTU: AppArmor: implement mmap_min_addr check as done in mainline.
> >     OriginalAuthor: John Johansen <jjohansen at suse.de>
> > 
> >     Implement the missing mmap_min_addr check in AppArmor mmap wrapper.
> > 
> >     Signed-off-by: John Johansen <jjohansen at suse.de>
> >     Signed-off-by: Kees Cook <kees.cook at canonical.com>
> > 
> > Any idea what's going on here? Is this a valgrind bug or an apparmor
> > bug? Note that it doesn't seem to happen with things like 'valgrind ls'.
> 
> That change was made for the release kernel, so you should see it with
> -16 too.  Blocking NULL is a feature.  :)
> 
> Why is ssh-add trying to allocate memory at 0x0?

>From what I can tell, mmap'ing to 0x0(NULL) is perfectly legitimate.
>From mmap(2):

....
        If start is NULL, then the kernel chooses the address at which
        to create the mapping; this is  the  most portable  method  of
        creating  a new mapping.  If start is not NULL, then the kernel
        takes it as a hint about where to place the mapping; on Linux,
        the mapping will be created at the next higher  page  boundary.
        The address of the new mapping is returned as the result of the
        call.
....

Being that it is the most portable method, it should probably not fail
by default :) Perhaps the check should be for values > 0x0, but less
than some (dangerous?) lower boundary.

> -Kees
> 
> -- 
> Kees Cook
> Ubuntu Security Team
>