[PATCH v5 2/4] Add system-wide tunables: cache ld.so.cache

[Adhemerval Zanella Netto]

On 02/03/26 09:48, Yury Khrustalev wrote:
> On Mon, Mar 02, 2026 at 09:27:16AM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 02/03/26 08:05, Yury Khrustalev wrote:
>>> On Fri, Feb 27, 2026 at 03:36:26PM -0300, Adhemerval Zanella Netto wrote:
>>>>
>>>> ...
>>>>
>>>> I agree with Yury here that we need to add some tests, at least some
>>>> minimal one that stress the ld.so.cache reload (which is not the usual
>>>> scenario).  I would suggest add test-containts tests that:
>>>>
>>>>   1. Construct a ld.so.cache, start the test, trigger ld.so.cache
>>>>      reconstruct, and check if:
>>>>
>>>>      1.1. A new entry is used on dlopen.
>>>>
>>>>      1.2. If removing an entry triggers a dlopen failure.
>>>>
>>>>      1.3. If not modifying the ld.so.cache contents keep the same
>>>>           contents.
>>>>
>>>>   2. Construct a ld.so.cache, start the test, create a invalid/corrupt
>>>>      ld.so.cache and check if the test can load new libraries to
>>>>      assure the cached load keeps working.
>>>
>>> I appreciate that this is a feature creep which is of course not ideal,
>>> however, this is important, so I'm happy to lend a hand to write these
>>> tests. DJ, can we co-ordinate this between us?
>>
>> Do you mean the feature creep the cached ld.so.cache concept or the extra
>> tests required?
> 
> I mean that these tests should've been written before this change, so
> adding the tests should become a separate patch. Once it's merged, we
> can come back here, rebase and continue review.

Right, I would prefer to have this tests *along* the patch itself to 
prove that all the semantic changes are covered with some regression
test.  But, considering that this kind of changes are highly unlikely
to be backported I think we can have the tests as a different patch.

> 
>> The ld.so.cache cache is not strictly required as far I understand. We
>> can construct the tunable setup during process startup by merging the 
>> system-wide configurations. The tunable_list (dl-tunable-list.h) is marked
>> as attribute_relro and I think it makes sense to keep it invariant during
>> process startup (so the cache reload should *not* change tunable value).
> 
> If ld.so.cache handling is not required for system-wide tunables, then
> perhaps we can simplify this patch? I thought it was necessary, maybe I
> have misunderstood?

This is my understanding. What is crucial for system-wide tunable is the
design on how we define them and which configure file to use, how we 
write down the binary format, when and how we parse it, and how does it
interact with the environment variable.  

> 
> Some tunables are updated during start-up (e.g. while checking all DSO
> dependencies). This is not ideal probably.
> 
> I agree that tunable values must not change during process lifetime
> (after they were merged and (re-)calculated during startup).

I think keeping them immutable during process execution simplifies
*a lot* the system-wide work, otherwise we will need to add additional
tunable constrains to have immutable tunable that can not be changed
during process execution (the security/harderning ones).