mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED

[Alexander Best]

hi there,

just a little mmap(2) related question. running the following code causes a
segfault:

mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );

while the following doesn't:

mmap( (void*)0x1000, 0xffffffff, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );

is this a known problem? seems reproducible on all branches.

cheers
alex

#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
        printf("mmap: %p\n", mmap( (void*)0x1000, 0xffffffff, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 ));
        printf("mmap: %p\n", mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 ));

        return 0;
}

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Nate Eldredge-4]

On Wed, 21 Oct 2009, Alexander Best wrote:

> hi there,

This is on a 32-bit platform I take it?

> just a little mmap(2) related question. running the following code causes a
> segfault:
>
> mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );

I don't doubt it.  You mapped over a big chunk of your address space with
memory that's inaccessible (PROT_NONE).  This probably includes your
program's code.  So when the mmap call returns from the kernel and tries
to execute the next instruction of your program, it finds that the
instruction pointer is pointing to inaccessible memory.  Result: segfault.
This is quite normal.

What are you actually trying to accomplish with this?

> while the following doesn't:
>
> mmap( (void*)0x1000, 0xffffffff, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );

Did you check whether the mmap actually succeeded?  I bet it didn't.  You
have a length that isn't a multiple of the page size and wraps around 32
bits.  I bet you got an EINVAL, and the mmap call didn't actually do
anything.

> is this a known problem? seems reproducible on all branches.

Not a problem at all, I suspect.

--

Nate Eldredge
nate@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Nate Eldredge schrieb am 2009-10-21:
> On Wed, 21 Oct 2009, Alexander Best wrote:

> >hi there,

> This is on a 32-bit platform I take it?

yes.

> >just a little mmap(2) related question. running the following code
> >causes a
> >segfault:

> >mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1,
> >0 );

> I don't doubt it.  You mapped over a big chunk of your address space
> with memory that's inaccessible (PROT_NONE).  This probably includes
> your program's code.  So when the mmap call returns from the kernel
> and tries to execute the next instruction of your program, it finds
> that the instruction pointer is pointing to inaccessible memory.
> Result: segfault. This is quite normal.

> What are you actually trying to accomplish with this?

this code serves only one purpose: to trigger a segfault. i don't use the code
for any other purpose. i was under the impression that mmap() should either
succeed or fail (tertium non datur). mmap's manual doesn't say anything about
mmap() causing segfaults.

from your description of the problem i don't think there's a quick fix to it.
so it might be a good idea to add this case to the mmap(2) bug section.

> >while the following doesn't:

> >mmap( (void*)0x1000, 0xffffffff, PROT_NONE, MAP_ANON|MAP_FIXED, -1,
> >0 );

> Did you check whether the mmap actually succeeded?  I bet it didn't.
>  You have a length that isn't a multiple of the page size and wraps
> around 32 bits.  I bet you got an EINVAL, and the mmap call didn't
> actually do anything.

> >is this a known problem? seems reproducible on all branches.

> Not a problem at all, I suspect.

> --

indeed the mmap() call fails with EINVAL but it doesn't segfault. to make this
clear: i don't expect either one of the  mmap() calls to succeed.

> Nate Eldredge
> nate@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert Watson]

On Wed, 21 Oct 2009, Alexander Best wrote:

> this code serves only one purpose: to trigger a segfault. i don't use the
> code for any other purpose. i was under the impression that mmap() should
> either succeed or fail (tertium non datur). mmap's manual doesn't say
> anything about mmap() causing segfaults.

Have you tried ktracing the application?  I think you'll find that mmap(2)
system call succeeded fine, and that the segfault comes from attempting to
execute the address in libc on return to userspace, as a result of libc not
being at that address anymore (since you removed its mapping).  You can use
procstat -v to inspect address space use by processes, but as a general rule
you don't want to pass anything other than an address of 0x0 to mmap(2) unless
you're very carefully managing the address space of the process.  Many
userspace libraries are involved in using that address space, but especially
the runtime linker which begins execution in userspace when a binary is
started.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Robert Watson schrieb am 2009-10-21:

> On Wed, 21 Oct 2009, Alexander Best wrote:

> >this code serves only one purpose: to trigger a segfault. i don't
> >use the code for any other purpose. i was under the impression that
> >mmap() should either succeed or fail (tertium non datur). mmap's
> >manual doesn't say anything about mmap() causing segfaults.

> Have you tried ktracing the application?  I think you'll find that
> mmap(2) system call succeeded fine, and that the segfault comes from
> attempting to execute the address in libc on return to userspace, as
> a result of libc not being at that address anymore (since you
> removed its mapping).  You can use procstat -v to inspect address
> space use by processes, but as a general rule you don't want to pass
> anything other than an address of 0x0 to mmap(2) unless you're very
> carefully managing the address space of the process.  Many userspace
> libraries are involved in using that address space, but especially
> the runtime linker which begins execution in userspace when a binary
> is started.

> Robert N M Watson
> Computer Laboratory
> University of Cambridge


you're right. this kdump shows that the segfault isn't being caused by the
mmap() call:

 88343 mmap_test CALL
 mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0xffffffff,0,0)
 88343 mmap_test RET   mmap 4096/0x1000
 88343 mmap_test PSIG  SIGSEGV SIG_DFL
 88343 mmap_test NAMI  "mmap_test.core"

thanks for clearing things up.

however i stil think mentioning this situation in the mmap(2) manual (maybe in
section MAP_FIXED) would be a good idea.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[jhb-3]

On Wednesday 21 October 2009 11:30:51 am Alexander Best wrote:

> Robert Watson schrieb am 2009-10-21:
>
> > On Wed, 21 Oct 2009, Alexander Best wrote:
>
> > >this code serves only one purpose: to trigger a segfault. i don't
> > >use the code for any other purpose. i was under the impression that
> > >mmap() should either succeed or fail (tertium non datur). mmap's
> > >manual doesn't say anything about mmap() causing segfaults.
>
> > Have you tried ktracing the application?  I think you'll find that
> > mmap(2) system call succeeded fine, and that the segfault comes from
> > attempting to execute the address in libc on return to userspace, as
> > a result of libc not being at that address anymore (since you
> > removed its mapping).  You can use procstat -v to inspect address
> > space use by processes, but as a general rule you don't want to pass
> > anything other than an address of 0x0 to mmap(2) unless you're very
> > carefully managing the address space of the process.  Many userspace
> > libraries are involved in using that address space, but especially
> > the runtime linker which begins execution in userspace when a binary
> > is started.
>
> > Robert N M Watson
> > Computer Laboratory
> > University of Cambridge
>
>
> you're right. this kdump shows that the segfault isn't being caused by the
> mmap() call:
>
>  88343 mmap_test CALL
>  mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0xffffffff,0,0)
>  88343 mmap_test RET   mmap 4096/0x1000
>  88343 mmap_test PSIG  SIGSEGV SIG_DFL
>  88343 mmap_test NAMI  "mmap_test.core"
>
> thanks for clearing things up.
>
> however i stil think mentioning this situation in the mmap(2) manual (maybe in
> section MAP_FIXED) would be a good idea.

I'm not sure it is useful to attempt to enumerate all the possible ways one
can shoot one's own foot using mmap(2) in the manual page.  The list would be
quite long and would require a large amount of imagination.  In effect, you
are asking for a manual page to document all the possible bugs one could have
and manual pages in general do not do that.

--
John Baldwin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

John Baldwin schrieb am 2009-10-21:
> On Wednesday 21 October 2009 11:30:51 am Alexander Best wrote:
> > Robert Watson schrieb am 2009-10-21:

> > > On Wed, 21 Oct 2009, Alexander Best wrote:

> > > >this code serves only one purpose: to trigger a segfault. i
> > > >don't
> > > >use the code for any other purpose. i was under the impression
> > > >that
> > > >mmap() should either succeed or fail (tertium non datur). mmap's
> > > >manual doesn't say anything about mmap() causing segfaults.

> > > Have you tried ktracing the application?  I think you'll find
> > > that
> > > mmap(2) system call succeeded fine, and that the segfault comes
> > > from
> > > attempting to execute the address in libc on return to userspace,
> > > as
> > > a result of libc not being at that address anymore (since you
> > > removed its mapping).  You can use procstat -v to inspect address
> > > space use by processes, but as a general rule you don't want to
> > > pass
> > > anything other than an address of 0x0 to mmap(2) unless you're
> > > very
> > > carefully managing the address space of the process.  Many
> > > userspace
> > > libraries are involved in using that address space, but
> > > especially
> > > the runtime linker which begins execution in userspace when a
> > > binary
> > > is started.

> > > Robert N M Watson
> > > Computer Laboratory
> > > University of Cambridge


> > you're right. this kdump shows that the segfault isn't being caused
> > by the
> > mmap() call:

> >  88343 mmap_test CALL
> >  mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0xffffffff,0,0)
> >  88343 mmap_test RET   mmap 4096/0x1000
> >  88343 mmap_test PSIG  SIGSEGV SIG_DFL
> >  88343 mmap_test NAMI  "mmap_test.core"

> > thanks for clearing things up.

> > however i stil think mentioning this situation in the mmap(2)
> > manual (maybe in
> > section MAP_FIXED) would be a good idea.

> I'm not sure it is useful to attempt to enumerate all the possible
> ways one
> can shoot one's own foot using mmap(2) in the manual page.  The list
> would be
> quite long and would require a large amount of imagination.  In
> effect, you
> are asking for a manual page to document all the possible bugs one
> could have
> and manual pages in general do not do that.

you're probably right. documenting all things one can do wrong using mmap
isn't what the manual is supposed to do.

thanks for the help.

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."