MFC r361995-r361996, r361999, r362111: posix_spawnp fixes

r361995:
execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two details:

argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().

The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:

"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."

So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.

Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.

This is a secondary change in D25038.

r361996:
execvPe: obviate the need for potentially large stack allocations

Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segment on the stack
large enough to hold PATH so that it may be mutated and use strsep() for
easy parsing. This logic is now rewritten to just operate on the immutable
string passed in and do the necessary math to extract individual paths,
since it will be copying out those segments to another buffer anyways and
piecing them together with the name for a full path.

Additional size is also needed for the stack in posix_spawnp(), because it
may need to push all of argv to the stack and rebuild the command with sh in
front of it. We'll make sure it's properly aligned for the new thread, but
future work should likely make rfork_thread a little easier to use by
ensuring proper alignment.

Some trivial cleanup has been done with a couple of error writes, moving
strings into char arrays for use with the less fragile sizeof().

r361999:
Add missing shell script from r361995

r362111:
posix_spawn: fix for some custom allocator setups

libc cannot assume that aligned_alloc and free come from jemalloc, or that
any application providing its own malloc and free is actually providing
aligned_alloc.

Switch back to malloc and just make sure we're passing a properly aligned
stack into rfork_thread, as an application perhaps can't reasonably replace
just malloc or just free without headaches.

This unbreaks ksh93 after r361996, which provides malloc/free but no
aligned_alloc.

MFC 356951: posix_spawn: mark error as volatile

In the case of an error, the RFSPAWN'd thread will write back to psa->error
with the correct exit code. Mark this as volatile as the return value is
being actively dorked up for erroneous exits on !x86.

This fixes the following tests, tested on aarch64 (only under qemu, at the
moment):

- posix_spawn/spawn_test:t_spawn_missing
- posix_spawn/spawn_test:t_spawn_nonexec
- posix_spawn/spawn_test:t_spawn_zero

MFC r352711-r352712: Address posix_spawn(3) signal issues

r352711:
rfork(2): add RFSPAWN flag

When RFSPAWN is passed, rfork exhibits vfork(2) semantics but also resets
signal handlers in the child during creation to avoid a point of corruption
of parent state from the child.

This flag will be used by posix_spawn(3) to handle potential signal issues.

Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D19058

r352712:
posix_spawn(3): handle potential signal issues with vfork

Described in [1], signal handlers running in a vfork child have
opportunities to corrupt the parent's state. Address this by adding a new
rfork(2) flag, RFSPAWN, that has vfork(2) semantics but also resets signal
handlers in the child during creation.

x86 uses rfork_thread(3) instead of a direct rfork(2) because rfork with
RFMEM/RFSPAWN cannot work when the return address is stored on the stack --
further information about this problem is described under RFMEM in the
rfork(2) man page.

Addressing this has been identified as a prerequisite to using posix_spawn
in subprocess on FreeBSD [2].

[1] https://ewontfix.com/7/
[2] https://bugs.python.org/issue35823

Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Fix Coverity CID 1016714 Resource leak in process_file_actions_entry()

Don't leak a file descriptor of _dup2() fails (shouldn't happen).

Reported by: Coverity
CID: 1016714
MFC after: 1 week

Fix a mistake in r287292. Despite correctly stating intent in the
comment above, POSIX_SPAWN_SETSIGMASK and POSIX_SPAWN_SETSIGDEF
handlers used libthr interposed functions instead of syscalls.

Noted by: jilles
Sponsored by: The FreeBSD Foundation
MFC after: 6 days

Switch libc from using _sig{procmask,action,suspend} symbols, which
are aliases for the syscall stubs and are plt-interposed, to the
libc-private aliases of internally interposed sigprocmask() etc.

Since e.g. _sigaction is not interposed by libthr, calling signal()
removes thr_sighandler() from the handler slot etc. The result was
breaking signal semantic and rtld locking.

The added __libc_sigprocmask and other symbols are hidden, they are
not exported and cannot be called through PLT. The setjmp/longjmp
functions for x86 were changed to use direct calls, and since
PIC_PROLOGUE only needed for functional PLT indirection on i386, it is
removed as well.

The PowerPC bug of calling the syscall directly in the setjmp/longjmp
implementation is kept as is.

Reported by: Pete French <petefrench@ingresso.co.uk>
Tested by: Michiel Boland <boland37@xs4all.nl>
Reviewed by: jilles (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

posix_spawn: If an error is detected in the child process, reap the zombie.

Formerly, in this case an error was returned but the pid was also returned
to the application, requiring the application to use unspecified behaviour
(the returned pid in error situations) to avoid zombies.

Now, reap the zombie and do not return the pid.

MFC after: 2 weeks

Fix whitespace inconsistencies in libc in files copyrighted by me.

posix_spawn(): Do not fail when trying to close an fd that is not open.

As noted in Austin Group issue #370 (an interpretation has been issued),
failing posix_spawn() because an fd specified with
posix_spawn_file_actions_addclose() is not open is unnecessarily harsh, and
there are existing implementations that do not fail posix_spawn() for this
reason.

Reviewed by: ed
MFC after: 10 days

Fix a typo.

Approved by: kib (mentor)

Turn execvpe() into an internal libc routine.

Adding exevpe() has caused some ports to break. Even though execvpe() is
a useful routine, it does not conform to any standards.

This patch is a little bit different from the patch sent to the mailing
list. I forgot to remove execvpe from the Symbol.map (which does not
seem to miscompile libc, though).

Reviewed by: davidxu
Approved by: philip

Process spawn attributes in POSIX document order.

Style fix.

Change my email address to the one from the FreeBSD project.

Approved by: philip (mentor, implicit), davidxu

Add POSIX routines called posix_spawn() and posix_spawnp(), which
can be used as replacements for exec/fork in a lot of cases. This
change also added execvpe() which allows environment variable
PATH to be used for searching executable file, it is used for
implementing posix_spawnp().

PR: standards/122051