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

[Adhemerval Zanella Netto]

On 23/12/24 14:33, Florian Weimer wrote:
> * 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.)

Ack, I will use the NEWS entry as a based for this part.

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

Ack, and it does 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.
> ”

Ack.

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