[PATCH v6 3/3] elf: Add glibc.rtld.execstack

[Florian Weimer]

* Adhemerval Zanella:

> diff --git a/manual/tunables.texi b/manual/tunables.texi
> index 0b1b2898c0..c3e894f4fe 100644
> --- a/manual/tunables.texi
> +++ b/manual/tunables.texi
> @@ -355,6 +355,25 @@ tests for @code{AT_SECURE} programs and not meant to be a security feature.
>  The default value of this tunable is @samp{0}.
>  @end deftp
>  
> +@deftp Tunable glibc.rtld.execstack
> +@theglibc{} will use either the default architecture ABI flags (that might
> +contain the executable bit) or the value of @code{PT_GNU_STACK} (if present)
> +to define whether to mark the stack non-executable, and if the program or
> +any shared library dependency require an executable stack the loader will
> +change the main stack permission if kernel starts with a non executable stack.
> +
> +The @code{glibc.rtld.execstack} tunable allows the user to control how
> +to proceed regarding the stack execution bit.  Setting its value to @code{0}
> +disables executable stacks, where @code{1} enables it. The default value
> +is @code{1}.

Isn't this quite misleading?  As far as I understand it, 0 disables
auto-negotiation (not executable stacks, see below), and 1 enables
auto-negotiation.  In both cases, stacks can end up executable or
non-executable from a functionality point of view.  This would perhaps
be cleaner to explain if there was a mode that disables
auto-negotiation, but tries to enable executable stacks if possible at
all; that could help with the dlopen issue mentioned below, too.  (The
NEWS entry is much clearer in this regard.)

> +When executable stacks are not allowed, and if the main program requires an
> +executable stack, the loader will fail with an error message.
> +@strong{NB:} Trying to load a dynamic shared library with @code{dlopen} or
> +@code{dlmopen} that requires an executable stack will always fail if the
> +default flags does not contain the executable bit.
> +@end deftp

Missing paragraph break before @strong{NB:}.  I think this needs to be
rephrased so that it's clear that this is true regardless the setting of
the tunable.  And I assume the gating factor is whether an executable
stack was initially enabled at process startup (for whatever reason),
not what the “default flags” (where?) say.  At least I hope the
implementation behaves this way.

Maybe also add:

“
Some systems do not have separate page protection flags at the hardware
level for read access and execute access (sometimes referred to as
read-implies-exec).  This mode can also be enabled on certain systems
where the hardware supports separate protection flags.  The glibc
tunable configuration is independent of hardware capabilities and kernel
configuration.
”

This doesn't explain that the kernel tracks PROT_EXEC in software even
if the hardware does not enforce it, but this level of detail probably
isn't required here.

Thanks,
Florian