Re: GDB testsuite: »Memory at address 0 is possibly executable«

[Samuel Thibault]

Justus Winter, le Sat 13 Sep 2014 02:40:17 +0200, a écrit :
> Quoting Samuel Thibault (2014-09-13 01:39:05)
> > So it seems we need what is not actually documented, i.e. a vm_map
> > with anywhere=1, but which takes into account the suggested address.
> > I'm fine with officially supporting that, we just need to fix the
> > documentation,
> 
> I'm sorry, I'm lost.  What other interpretation of 'anywhere' is
> there?

Not taking the address into account at all.

> And since you aligned the semantic of vm_maps 'anywhere' with
> 'vm_allocate', then it follows that the current interpretation is
> either wrong or right for both functions, no?

Well, it depends what is documented :)

> I just looked at mmap(2).  If one specifies a non-NULL address, Linux
> will use the address as hint.  If it is NULL, and MAP_FIXED is not
> given, Linux choses a suitable address.  It isn't explicitly stated,
> but I'm pretty sure the Linux kernel doesn't consider the zero page a
> suitable place.

Sure, that's the common Unix semantic, and our mmap implements this from
the documented gnumach behavior by trying the suggested address first
with anywhere=0, then anywhere=1.

> > and fix all places which weren't aware of this behavior (there are
> > very few).
> 
> How would I chose a suitable address?  E.g. ext2fs/dir.c initializes
> the address to 0, but then vm_map_enter would set it to
> map->min_offset anyway (or map->min_offset is 0), which is the same as
> vm_map_min(map).

I've dug a bit more, glibc's _hurd_startup reserves page 0, so no vm_map
or vm_allocate call should be allocating at address 0. But with the
change, address 0 is already taken by the first mapped binary, ld.so. I
guess exec needs to be fixed, and then we can keep the documented
behavior.

Samuel