Hi

Wiz reported me a bug in COMPAT_LINUX/powerpc that might be an unwanted
consequence of non executable mappings: Linux's ldconfig will randomly
crash with either SIGSEGV or SIGILL.

Tracking down the problem with GDB, it occurs always at the same place,
in a function called __DTOR_END__:

Program received signal SIGILL, Illegal instruction.
0x1007ff84 in __DTOR_END__ ()
(gdb) x/1i $pc
0x1007ff84 <__DTOR_END__+4>:    blrl

The instruction is perfectly legal, I assume the problem is just that
the memory is mapped as non executable. 

This function comes from the .dtors ELF section:

 12 .dtors        00000008  1007ff4c  1007ff4c  0006ff4c  2**2
                  CONTENTS, ALLOC, LOAD, DATA

ldconfig is a static binary, the section has LOAD set, so as I
understand, it's the kernel's job to load that section. It's done in
elf32_load_file() and elf32_load_psection()

This section is not CODE, it's DATA, so we load it without the execute
bit set, and this is the cause of the problem.

Questions:
1) Do I understand the proble correctly?

2) How does it affect other ports and other COMPAT_* options? As a lot
of OSes don't support non executable mappings, so I beleive we break
many things by defaulting to non executable mappings for them. I already
had to modify linux_exec_setup_stack() to get dynamic Linux/PowerPC
binaries linking again. I suspect the problem exists for other ports as
well.

3) How to fix it properly? I'm not sure duplicating the whole
elf32_load_psection() is a good idea. The other way would be to flag the
exec package as wanting execute bits everywhere, and add a test for that
in elf32_load_psection() and exec_setup_stack() 

If we go that way, it woulds probably make sense to have a sysctl to
force non executable mappings for OSes that don't support them: it may
break things but you get more security.

4) Do we want to fix that for 2.0?
 
-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org