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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Mon Mar 2 12:27:16 GMT 2026



On 02/03/26 08:05, Yury Khrustalev wrote:
> On Fri, Feb 27, 2026 at 03:36:26PM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 21/02/24 20:47, DJ Delorie wrote:
>>>
>>> The purpose of this change is twofold:
>>>
>>> 1. The ld.so.cache is cached in memory and only re-read if/when
>>>    it changes on disk.  This allows us to have much more intensive
>>>    security checks in the future, without impacting performance as
>>>    much.  It also allows for cases where the cache is corrupted -
>>>    we continue using the last valid one.
>>>
>>> 2. We break out the load/check logic so that the cache can be
>>>    loaded independently of the library lookup, such as for
>>>    code that only needs to look at the extensions.
>>
>> 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?

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


More information about the Libc-alpha mailing list