[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