Chuck Silvers <chuq@chuq.com> wrote:

> > 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. 
> it would be safest to default to making everything executable for other
> emulations until it can be verified that those binaries work ok with
> non-executable mappings.  this seems fine to me.

IS there a way to check that? If signal delivery is okay, where can it
break?
 
> > 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()  
> let's use a flag in struct emul to enable it (and undo the duplication of
> exec_setup_stack() that you already added).  

I propose P_NOEXECMAP, defined to 1 for native binaries, defaulting to 0
for everything else.

> let's check the flag in
> the vmcmd_* functions instead of in all the emulation code.

We can modify the required protection mask and add an execute bit if
P_NOEXECMAP is no set, in the following functions:
vmcmd_map_pagedvn()
vmcmd_readvn()
vmcmd_map_zero()
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. 
> that would be fine.  do we have support for per-emulation sysctls?

We can do that for the next binary executed by execve and inherit the
property accross forks. That way it would be available on a per-process
basis, and it would even be usable for ill-programmed NetBSD binaries
that non executable mappings broke. What about something like this?

sysctl -w proc.$$.noexecmap=1 

But that would end up with eating one more bit in struct proc, to tell
that the P_NOEXECMAP bit is forced and should not be modified to a
per-emulation default value at execve time.
  
> > 4) Do we want to fix that for 2.0? 
> we'll know better once we see what the diffs look like.
> so far it sounds simple enough that there wouldn't be much risk.
> (we could leave out the sysctl stuff until later, if that helps.)

I have to sort out other trouble with iBook G4 before working on it (not
enough disk space to build two kernels). I hope I'll be able to propose
a patch soon.

-- 
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