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

DJ Delorie dj@redhat.com
Mon Jun 15 19:27:49 GMT 2026


Yury Khrustalev <yury.khrustalev@arm.com> writes:
>> Add support for filtering out AT_SECURE or non-AT_SECURE binaries:
>
> Does this commit also add support for !tunable, +tunable, and -tunable?

No.  I intentionally left that out for now as it touches a wider
codebase and needs more care and testing.

>>   $glibc.only-for.unsecure-binaries=1
>>   @glibc.only-for.secure-binaries=1
>
> More complications :)

You don't *need* to use the complications ;-)

>> +tst-tunconf1-ENV = GLIBC_TUNABLES=glibc.malloc.tcache_count=5
>> +
>
> Could you use the new shiny
>
>   tst-tunconf1-TUNABLES += glibc.malloc.tcache_count=5

Fixed.
>> +	  printf("  [%d] %s (%d) : %s [flags 0x%08x",
>>  		 i,
>>  		 cache_data + tec[i].name_offset,
>> +		 tec[i].tunable_id,
>
> What is tunable id? Does it mean something to a user reading output
> from ldconfig -p?

My philosophy was "if it's in the file, it gets printed" but I took it
out.  The string is authoritative, the tunable id is "just a shortcut".

>> +#define TUNCONF_EXCLUDE_SECURE		0x00000010
>> +#define TUNCONF_EXCLUDE_UNSECURE	0x00000020
>> +
>
> Again, not sure why we need this at this stage.

Florian argued for the AT_SECURE stuff because such binaries *already*
filter tunables, and tunables.conf becomes the only way to set these
tunables for those processes - but for security reasons, it should be
controllable.  So because it affects AT_SECURE we need to implement it
sooner than the other filters.



More information about the Libc-alpha mailing list