Re: [PATCH] elf: Make string tunables startup-only
Adhemerval Zanella Netto <[email protected]> Wed, 29 Jul 2026 15:56:43 -0300
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | Linaro |
| Message-ID | <[email protected]> |
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.