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

  Add support for [proc:*] syntax where * matches /proc/self/exe
(fallback: argv[0] unless AT_SECURE).  Tunables after such a
line are limited to matching processes.

Note that this filter is reset when including a file or at
end of file.

If the filename starts with a slash (example: [proc:/bin/foo]) the
full path must match.  If not (example: [proc:foo]) the basename is
matched.

Add support for filtering out AT_SECURE or non-AT_SECURE binaries:

  $glibc.only-for.unsecure-binaries=1
  @glibc.only-for.secure-binaries=1
---
 csu/libc-start.c                        |   2 +-
 elf/Makefile                            |   4 +
 elf/cache.c                             |   3 +-
 elf/dl-tunables.c                       |  80 +++++++++++++++-
 elf/dl-tunables.h                       |   2 +-
 elf/ldconfig-parse.c                    |   6 +-
 elf/ldconfig.c                          |   3 +
 elf/tst-tunconf1.c                      |  36 +++++++
 elf/tst-tunconf1.root/etc/tunables.conf |  15 +++
 elf/tst-tunconf1.root/ldconfig.run      |   0
 elf/tst-tunconf1.root/postclean.req     |   0
 elf/tunconf.c                           | 122 +++++++++++++++++++++++-
 elf/tunconf.h                           |   3 +
 sysdeps/mach/hurd/dl-sysdep.c           |   2 +-
 sysdeps/unix/sysv/linux/dl-sysdep.c     |   2 +-
 15 files changed, 265 insertions(+), 15 deletions(-)
 create mode 100644 elf/tst-tunconf1.c
 create mode 100644 elf/tst-tunconf1.root/etc/tunables.conf
 create mode 100644 elf/tst-tunconf1.root/ldconfig.run
 create mode 100644 elf/tst-tunconf1.root/postclean.req
  

Hello DJ,

On Mon, Mar 16, 2026 at 09:39:39PM -0400, DJ Delorie wrote:
> 
> Add support for [proc:*] syntax where * matches /proc/self/exe
> (fallback: argv[0] unless AT_SECURE).  Tunables after such a
> line are limited to matching processes.
> 
> Note that this filter is reset when including a file or at
> end of file.
> 
> If the filename starts with a slash (example: [proc:/bin/foo]) the
> full path must match.  If not (example: [proc:foo]) the basename is
> matched.
> 
> Add support for filtering out AT_SECURE or non-AT_SECURE binaries:
> 
>   $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.

> 
> ...
>
> diff --git a/csu/libc-start.c b/csu/libc-start.c
> index 1c58561bce..ae36170045 100644
> --- a/csu/libc-start.c
> +++ b/csu/libc-start.c
> @@ -264,7 +264,7 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL),
>    _dl_aux_init (auxvec);
>  # endif
>  
> -  __tunables_init (__environ);
> +  __tunables_init (__environ, argv);

Nit: For some deeply intrinsic reason I prefer argv to go first.

>  
>    ARCH_INIT_CPU_FEATURES ();
>  
> diff --git a/elf/Makefile b/elf/Makefile
> index 5398fe0d2c..4fbd03cefc 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -323,6 +323,7 @@ tests-internal := \
>    $(tests-static-internal) \
>    tst-tls1 \
>    tst-tls_tp_offset \
> +  tst-tunconf1 \
>    # tests-internal
>  
>  tests-static := $(tests-static-normal) $(tests-static-internal)
> @@ -333,6 +334,8 @@ tests-static += \
>    tst-tls9-static \
>    # tests-static
>  
> +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?

In this test we probably should have the same tunable in both
environment and tunables.conf, and the test should check that
whatever has higher priority applies.

> 
> ...
> 
> diff --git a/elf/dl-tunables.c b/elf/dl-tunables.c
> index 29fcd4504b..acee6eb872 100644
> --- a/elf/dl-tunables.c
> +++ b/elf/dl-tunables.c
> @@ -291,13 +291,22 @@ parse_tunables (const char *valstring)
>     ENV_ALIAS to find values.  Later we will also use the tunable names to find
>     values.  */
>  void
> -__tunables_init (char **envp)
> +__tunables_init (char **envp, char **argv)
> 
> ...
> 
> +
> +	  /* 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?

Thanks,
Yury
  

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

>> -  __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).  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?

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

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

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
  

Yury Khrustalev <yury.khrustalev@arm.com> writes:
> 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 think the config needs to be able to choose from these (ignoring the
defaults, for now, because we *always* have defaults):

  1) system-wide
  2) env var

  1) system-wide only

  1) env var only (by not mentioning it in tunables.conf)

The only other non-Sisyphean option would be:

  1) system-wide
  2) env var if numerically larger (closer to +Inf)

  1) system-wide
  2) env var if numerically smaller (closer to -Inf)

but that obviously won't include non-numeric tunables.
  

On Thu, Mar 26, 2026 at 01:38:50PM -0400, DJ Delorie wrote:
> 
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
> > 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 think the config needs to be able to choose from these (ignoring the
> defaults, for now, because we *always* have defaults):
> 
>   1) system-wide
>   2) env var
> 
>   1) system-wide only
> 
>   1) env var only (by not mentioning it in tunables.conf)
> 
> The only other non-Sisyphean option would be:
> 
>   1) system-wide
>   2) env var if numerically larger (closer to +Inf)

We should not take into account values of tunables. This would be a
mistake: like I said, some tunables don't have any monotonicity of
their values.

>   1) system-wide
>   2) env var if numerically smaller (closer to -Inf)

Ditto

> 
> but that obviously won't include non-numeric tunables.
> 

One more reason not to consider the values of tunables.

I think we should use the following approach:

1) Use default if not overridden (via env var or tunables.conf).
2) Env var overrides tunables.conf unless tunables.conf has special
   "final" marker for this tunable.

Plain and simple. Again, actual values of the tunables are irrelevant.
  

Yury Khrustalev <yury.khrustalev@arm.com> writes:
> We should not take into account values of tunables. This would be a
> mistake: like I said, some tunables don't have any monotonicity of
> their values.

True, but some tunables *do* and why not let the admin have the option?

Consider:

* Admin limits the number of malloc heaps to 16 because glibc
  autodetects the number of CPUs wrong.

* User further limits it to 1 to avoid heap-related fragmentation.
  

On Mon, Mar 30, 2026 at 12:03:36PM -0400, DJ Delorie wrote:
> Yury Khrustalev <yury.khrustalev@arm.com> writes:
> > We should not take into account values of tunables. This would be a
> > mistake: like I said, some tunables don't have any monotonicity of
> > their values.
> 
> True, but some tunables *do* and why not let the admin have the option?

Let's do it step by step. What I propose will cover all possible
scenarios: admin enforces a value (1), recommends a value (2), doesn't
care (3).

> 
> Consider:
> 
> * Admin limits the number of malloc heaps to 16 because glibc
>   autodetects the number of CPUs wrong.

This will complicate things and we would have to assess how useful this
use case is going to be before we try to implement it.

Plus, we probably should avoid making tunables.conf Turing-complete,
otherwise it will become a vulnerability of its own :) If you allow to
narrow down the accepted range, you'd have to support both upper and
lower boundary. This is doable, but I'd rather add this in another
patch, but only if there is some need for this.

> 
> * User further limits it to 1 to avoid heap-related fragmentation.

Also, as far as setting tunables is concerned, there is no notion of
"limiting" anything: we set a value if we want to use a non-default one.

In a nutshell, let's keep it simple. We could try adding scripting
support, GPU acceleration, and distributed compute a few decayed protons
later :)
  

Yury Khrustalev <yury.khrustalev@arm.com> writes:
> Let's do it step by step. What I propose will cover all possible
> scenarios: admin enforces a value (1), recommends a value (2), doesn't
> care (3).

Sure, I'm ok with only implementing the "overridable or not" feature at
first.  I'd like to leave the two-bit field to allow for two other
options later, though.  I think we can spare a bit for unseen future
needs, and I still think allowing an admin to permit bigger/smaller
values, has some value.

>> Consider:
>> 
>> * Admin limits the number of malloc heaps to 16 because glibc
>>   autodetects the number of CPUs wrong.
>
> This will complicate things and we would have to assess how useful this
> use case is going to be before we try to implement it.

I wasn't trying to justify the use case, just trying to demonstrate why
a bigger/smaller restriction might be useful to an admin.

> Plus, we probably should avoid making tunables.conf Turing-complete,

I offered to put a full LR(1) language in there with a byte code
interpreter, but Florian quickly stopped me ;-)

(I've done it before.  It's not that difficult.  Let me whip up a
patch... no?  are you sure?  well, ok...  ;)

> otherwise it will become a vulnerability of its own :) If you allow to
> narrow down the accepted range, you'd have to support both upper and
> lower boundary. This is doable, but I'd rather add this in another
> patch, but only if there is some need for this.

Later is OK.  Simple is good, I don't want to do a range, just
increase/decrease.

>> * User further limits it to 1 to avoid heap-related fragmentation.
>
> Also, as far as setting tunables is concerned, there is no notion of
> "limiting" anything: we set a value if we want to use a non-default one.

I was referring to the effect of the tunable.  That tunable
(malloc.arena_max) is a maximum, so it's action is to limit.