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);
> }
>
> /*
