[PATCH v6 1/2] elf: Do not duplicate the GLIBC_TUNABLES string

[Adhemerval Zanella Netto]

On 11/06/26 13:18, Andreas Schwab wrote:
> On Dez 06 2023, Adhemerval Zanella wrote:
> 
>> Since the environment variable is allocated on the stack by the kernel,
>> it is safe to keep the references to the suboptions for later parsing
>> of string tunables (as done by set_hwcaps by multiple architectures).
> 
> Is that true?  What is the expected lifetime of the string parameter?
> 

I think so, with one clarification.  That region that kernel setups for envp
strings stays mapped for the whole process lifetime; it is never freed or 
reused; and setenv functions only modify the environ pointer array.

What is not guaranteed is that the contents stay unmodified: the application may 
write through environ[i] (like setproctitle-style programs). However, all *current(
consumers of string tunables (the glibc.cpu.hwcaps parsing on 
x86/powerpc/s390x/loongarch and glibc.cpu.name on aarch64) read the value from 
init_cpu_features during early startup, before any application code can run.

I don't think we should re-introduce the tunables copying, so maybe we should properly 
ocument it on dl-tunables.c with a note that future string tunable that is read lazily
after startup would need to copy the value instead (a parse during process startup).
And we can then zero any string tunable_list before executing any user code.