Re: [PATCH 0/2] Check ld.so/libc.so consistency during startup

[Carlos O'Donell <carlos@redhat.com>]

On 8/19/22 06:16, Florian Weimer via Libc-alpha wrote:
> This avoids mysterious crashes and produces a clear error message
> instead.

The high-level idea here makes complete sense to me.

In my opinion the gold standard would be:

- If the interface between libc and ld.so was more formally defined then we would
  have a way to know if ld.so could use the the libc that the system was providing.

- The new ld.so is always installed first and knows about past libc interfaces and
  could choose to use a slightly older interface if possible.

We don't have that today, and I am not asking for you to implement this.

What I want to make sure is that what we implement retains some of the invariants
that such a design would have:

- ld.so is always installed first is generally maintained in rpm-based installs
  because of the file name ordering ld.so < libc.so
  - True for Fedora testing.

- ld.so needs to know if libc is new enough that it can work together.
  - Your patch uses a known symbol with a hash as the discriminator.

- ld.so provides better diagnostics if the requirements cannot be met.
  - Your patch provides a diagnostic.

I think your patch meets all of these conditions.

Where we loose a little bit here is that if a developer is making a non-ABI
change to the interface, and just rebuilding ld.so, this will immediately cause
that ld.so not to work with the libc in the build. This is a limited use case
that we can fix if developers report that their workloads are impacted. We
might change how to enable/disable this feature.

Of key importance is going to be the quality of the diagnostic message here
because that will be the first thing users see when they try to use ld.so
from outside of a container with a libc inside a container, and what used
to work by sheer luck may now fail with a diagnostic because of non-ABI
related changes.

We have always said this was unsupported, and now we try to enforce this,
and I can stand behind that technical enforcement.
 
> This helps somewhat with concurrent glibc updates on a live system
> because it inhibits coredumps resulting from mismatches.  This avoids
> secondary crashes from a coredump catching services that in turn crashes
> during launch while the update is in progress.  A full solution to the
> concurrent update problem will look very different.

Agreed.

> Tested on i686-linux-gnu and x86_64-linux-gnu.  Built with
> build-many-glibcs.py.
> 
> Thanks,
> Florian
> 
> Florian Weimer (2):
>   scripts/glibcelf.py: Add hashing support
>   Detect ld.so and libc.so version inconsistency during startup
> 
>  INSTALL                         |  9 ++++
>  Makerules                       | 14 ++++++
>  NEWS                            |  7 ++-
>  config.make.in                  |  1 +
>  configure                       | 11 +++++
>  configure.ac                    |  5 ++
>  csu/libc-start.c                |  1 +
>  elf/Versions                    |  4 +-
>  elf/dl-call-libc-early-init.c   |  9 ++--
>  elf/libc-early-init.h           |  9 +++-
>  elf/tst-glibcelf.py             | 19 ++++++++
>  manual/install.texi             |  9 ++++
>  scripts/glibcelf.py             | 19 ++++++++
>  scripts/libc_early_init_name.py | 85 +++++++++++++++++++++++++++++++++
>  14 files changed, 194 insertions(+), 8 deletions(-)
>  create mode 100644 scripts/libc_early_init_name.py
> 
> 
> base-commit: f7b0fc5cc61301461e3c1a278240ce78701bb9a8


-- 
Cheers,
Carlos.