[PATCH v6 4/4] Add system-wide tunables: Filters

[Yury Khrustalev]

On Wed, Mar 25, 2026 at 02:36:13PM -0400, DJ Delorie wrote:
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
> >>   $glibc.only-for.unsecure-binaries=1
> >>   @glibc.only-for.secure-binaries=1
> >
> > We probably need a bit information about /etc/tunables.conf in the
> > manual.
> 
> Agreed.  Writing up all the documentation is the next task on my list,
> but I'm trying to avoid this patch rotting for a couple more years while
> waiting for every little feature to be haggled over, reviewed, and
> committed.  This patch set is step 1 ;-)

Agreed.

> 
> >> -  __tunables_init (__environ);
> >> +  __tunables_init (__environ, argv);
> >
> > Nit: For some deeply intrinsic reason I prefer argv to go first.
> 
> I won't put in argc even if you ask ;-)
> 
> >> +tst-tunconf1-ENV = GLIBC_TUNABLES=glibc.malloc.tcache_count=5
> >
> > If I add glibc.malloc.tcache_max=42 to this line, the test fails.
> > It looks like the environment variable overrides tunables.conf,
> > is this intentional?
> 
> Yes!  At this point, all the security implementation is missing (aside
> from AT_SECURE, because that was easy).

Noted.

> The "problem" with the security
> model I chose is that each tunable needs some inherent logic about
> what's "more secure".  For numeric values, is a bigger one more secure,
> or a smaller one?  What about hwcaps?  Is adding a hwcap more secure, or
> removing one?  Does it depend on which hwcap?

OK, so I prefer to think about this in a different way. Whatever mechanism
we implement here, we should not have to understand the details of each
tunable. This would be Sisyphean effort. Some tunables are not supposed
to have "monotonicity" of their values.

We're adding 3rd way to provide a value for a tunable. So far we have:

 0) Default values
 1) Values from the GLIBC_TUNABLES environment variable.

Now we will have a value that comes from /etc/tunables.conf.

So, regardless of what each value actually means, we should decide
which source of this value is to be used where there are more than
one value provided for this tunable.

For example, right now, the value from GLIBC_TUNABLES overrides
the default value. Now, which one has higher priority, env var or
system-wide config?

I have an opinion here but I don't want to impose it :)

> I put the syntax in because it affects the file format and I didn't want
> to have to change that later.  I might end up skipping the "more secure"
> implementation and just do the "override or not" options, but even the,
> what does "do not override" mean for hwcaps?  Is it per-cap or the whole
> string?
> 
> Either way, it (like the docs and man pages) was intentionally left as a
> "next step".

I think we should decide on precedence at this point. Since it's not
dependent on which value is "better" or "more secure", we should be able
to do this.

> 
> >> +	  /* Apply selected filter, if any.  */
> >> +	  switch (tec->flags & TUNCONF_FLAG_FILTER) {
> >> +	  case TUNCONF_FILTER_PERPROC:
> >> +	    /* Perform one-time calculations that aren't needed if we
> >> +	       don't use this filter.  */
> >> +	    if (prog_name_len == -1)
> >> +	      {
> >> +		ssize_t n = readlink ("/proc/self/exe",
> >> +				      exebuf, sizeof (exebuf) - 1);
> >
> > Do we have to do this inside the for loop?
> 
> We only do it once, and only if the tunable has that filter.  I assume
> most systems will not even have a tunables.conf, much less a per-program
> filter, so I didn't want to do file I/O if not needed.

Ah, thanks for clarification, I haven't followed the code properly. What
you do makes sense.

Cheers,
Yury