Re: more fexecve questions

[maya%NetBSD.org@localhost]

Please add a comment explaining that this is for pathnames we can't
resolve in chroots.

> @@ -224,9 +225,11 @@ elf_populate_auxv(struct lwp *l, struct 
>  		a->a_v = l->l_proc->p_stackbase;
>  		a++;
>  
> -		execname = a;
> -		a->a_type = AT_SUN_EXECNAME;
> -		a++;
> +		if (path[0] == '/' && path[1] != '\0') {
> +			execname = a;
> +			a->a_type = AT_SUN_EXECNAME;
> +			a++;
> +		}
>  
>  		exec_free_emul_arg(pack);
>  	} else {



segvguard and veriexec ony use the name for printing error messages.
I don't think it's necessary to give up on them because of it.

segvguard even handles a NULL name already.


> +	if (epp->ep_resolvedname) {
>  #if NVERIEXEC > 0
> -	error = veriexec_verify(l, vp, epp->ep_resolvedname,
> -	    epp->ep_flags & EXEC_INDIR ? VERIEXEC_INDIRECT : VERIEXEC_DIRECT,
> -	    NULL);
> -	if (error)
> -		goto bad2;
> +		error = veriexec_verify(l, vp, epp->ep_resolvedname,
> +		    epp->ep_flags & EXEC_INDIR ? VERIEXEC_INDIRECT
> +		    : VERIEXEC_DIRECT, NULL);
> +		if (error)
> +			goto bad2;
>  #endif /* NVERIEXEC > 0 */
>  
>  #ifdef PAX_SEGVGUARD
> -	error = pax_segvguard(l, vp, epp->ep_resolvedname, false);
> -	if (error)
> -		goto bad2;
> +		error = pax_segvguard(l, vp, epp->ep_resolvedname, false);
> +		if (error)
> +			goto bad2;
>  #endif /* PAX_SEGVGUARD */
> +	}
>  


We really should stop stubbing out stuff like this. I wouldn't be
surprised if working around things would be easier if we didn't have the
function they're (rightly) feature-testing for.

(I had similar issues with fallocate...)

> @@ -559,7 +598,8 @@ sys_fexecve(struct lwp *l, const struct 
>  		syscallarg(char * const *)	envp;
>  	} */
>  
> -	return ENOSYS;
> +	return execve1(l, NULL, SCARG(uap, fd), SCARG(uap, argp),
> +	    SCARG(uap, envp), execve_fetch_element);
>  }
>  
>  /*