[PATCH] elf: Make string tunables startup-only

[Adhemerval Zanella Netto]

On 29/07/26 10:28, Adhemerval Zanella Netto wrote:
> 
> 
> On 29/07/26 09:56, Yury Khrustalev wrote:
>> On Wed, Jun 17, 2026 at 04:35:45PM -0300, Adhemerval Zanella wrote:
>>> String tunable values reference the GLIBC_TUNABLES (or alias) environment
>>> string, which lives in the environment block the kernel places on the
>>> initial stack.  That memory is owned by the application, which may
>>> overwrite it (e.g. setproctitle), so the references are only safe while no
>>> application code has run.  Until now this was an undocumented convention:
>>> every string tunable happened to be consumed by init_cpu_features during
>>> early startup.
>>>
>>> Make the lifetime explicit and enforced without copying the value or
>>> allocating any memory.  Add __tunable_seal_strings, which drops every
>>> string tunable reference (and marks each string tunable sealed) once early
>>> startup is complete, and have __tunable_get_val report a fatal error when
>>> a sealed string tunable is read.
>>>
>>> The seal is applied after the only string tunable consumer
>>> (init_cpu_features, run from DL_PLATFORM_INIT before dl_main, or from
>>> ARCH_INIT_CPU_FEATURES in __libc_start_main) but before any user code can
>>> run.  In particular it precedes the relocation phase, where IFUNC
>>> resolvers fire, and the constructors run later from _dl_init; it also
>>> precedes RELRO, which freezes the tunable list.
>>
>> Sounds good. I think it's a useful improvement and I have no question
>> for the implementation. A few comments on tests below.
>>
>> Just a thought: Should we seal string tunable as soon as it is read?

I don't think there is any requirement for that, and it would make internal
usage a bit more complex (callers will need to take this in consideration).
I think we can keep at loading time for now.

I just realized that the system-wide tunables changed the startup tunable
semantic (some value might the strdup instead of always reference the
environment variables), but I don' think they change seal concept.

I am adapting the patch to take this in consideration and adding some notes
to README.tunables.