[PATCH] elf: Add la_objsearch2 with lmid parameter for rtld-audit [BZ #34093]

[Adhemerval Zanella Netto]

On 29/09/26 07:44, Frederic Berat wrote:
> 
> 
> On Mon, Sep 28, 2026 at 9:05 PM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> wrote:
> 
> 
> 
>     On 23/09/26 17:27, DJ Delorie wrote:
>     > On Wed, Sep 23, 2026 at 3:55 PM Adhemerval Zanella Netto
>     > <adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>> wrote:
>     >> Right, but then you move the version check from glibc to the audit
>     >> module itself.  I am not sure if this is a better semantic.
>     >
>     > I think there's a couple of scenarios to consider:
>     >
>     > 1. Existing auditors will request the old LAV_CURRENT (say, 2).  New
>     >    glibc will need to support that version.  sysdeps/generic has the
>     >    right logic, but aarch64 and loongarch will need a range check
>     >    (currently they use ==) since the previous version is incompatible.
> 
>     I recall from previous discussion on other audit issues that backward
>     compatibility was not a constraint, so it should be ok to bump the
>     LAV_CURRENT at any time if required or when it simplifies deployment.
> 
>     This was based on the current consumers of these ABI (HPC related tools),
>     where the audit libraries are built and deployed targetting specific
>     symbol/glibc versions (and source compatibility is not a burden).
> 
>     >
>     > 2. A new auditor that allows but does not require the new function can
>     >    return the OLD version (LAV_CURRENT-1) and dynamically adapt to
>     >    whatever callbacks happen.
>     >
>     > 3. An auditor requires the new callback, is built with the new
>     >    headers, and will fail to load on old glibc's.
>     >
>     > 4. A new auditor wants the old callback, but builds with the new
>     >    LAV_CURRENT.
> 
>     Can this really happen? I think for version bump either the new callback
>     is a superset of the old one or it is a complete new function (and thus
>     new entrypoints during loading).
> 
>     The auditor requiring the old callback would meant that it is trying
>     to provide some backward compatibility.
> 
>     >
>     > I think bumping LAV_CURRENT will work in all cases.  Not bumping it
>     > works for 1 and 2 but not 3.
>     >
>     > Case 4 requires glibc internals to detect which is requested, which
>     > Fred's patch does.
>     >
>     > Case 2 is more flexible for auditor deployers but is trickier to code,
>     > especially as the LAV_CURRENT values are inconsistent across targets.
>     >
>     > The only time we MUST bump LAV_CURRENT is when an existing callback
>     > changes in a way that breaks existing auditors.
> 
>     Agree, but I also think by *not* providing backward compatibility it
>     simplifies a *lot* the constraints. But I might be wrong with this
>     assumption, and there is also whether we want to keep source
>     compatibility.
> 
> 
> After double checking, Florian is right about <link.h>, sticking with la_objsearch2 seems to be the cleaner way to avoid breaking existing builds.
> 
> If we go ahead and bump LAV_CURRENT to 3, here is how I'm planning to handle it:
> - Bump generic LAV_CURRENT to 3 and drop the LoongArch-specific header so all arches are in sync again.
> - Switch the AArch64 and LoongArch version checks to a range (lav >= 2 and lav >= 3 respectively) so we don't break existing auditors.
> Something like:
> {
>   /* Reject broken v1 auditors, but accept v2 and v3+. */
>   return lav >= 2 && lav <= LAV_CURRENT;
> }
> - Keep the ld.so fallback to la_objsearch when la_objsearch2 isn't exported.
> - Fix the xdlinfo check and update the test case to cover the fallback and actual library loads as Adhemerval pointed out.
> - Try to document all of that.
> 
> Does that sound like the right way forward to everyone before I send a v2? 

Sounds reasonable, thanks Frederic.