This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Enable preloading of new symbol versions [BZ #24974]

On 9/6/19 11:59 AM, Florian Weimer wrote:
> This commit adds the --no-version-coverage-check option to the
> dynamic loader, and the LD_NO_VERSION_COVERAGE_CHECK environment
> variable.
> The new _dl_no_version_coverage_check field in struct rtld_global_ro
> lands in previously-unused padding (on x86-64).

At a high level I like where you are going with this design.

I have some high level questions to ask, that way we can set the tone
for the overall design of the dynamic loader.

(a) Not a tunable, but use some tunable framework.

I assume this isn't a tunable because it changes the semantics of the
dynamic loader.

I would like us to avoid adding another env var since it will become
another variable that downstream needs to learn to "clean" from the
environment if they want to manage runtime behaviour.

My idea is that if we are going to add a new env var that it should
be the *last* one we add.

We should add a GLIBC_LDSO="glibc.ld.no_version_coverage_check=1" and
then extend GLIBC_LDSO to contain all existing legacy env vars etc.
You can reuse all of the tunables code to manage *one* env var that
can alter the behaviour of the dynamic loader, and this includes
reusing the well tested handling of security context and clearing.

There are ~20 env vars that can be cleaned up and put into legacy
handling like this.

(b) When does a user know to use this env var?

- Is one scenario like this:

  - They have an old library that doesn't provide all the symbols they need.
  - They implement a preload that provides the missing functionality.
  - They disable the check with an env var and run a newer program using 
    a mix of the old library and preload to provide all the required symbols.

Is that a valid scenario? We should document something like this in the NEWS

What other useful scenarios are supported by the change?

(c) Why not remove the check entirely?

What are the pros/cons of keeping or removing the check?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]