[PATCH v6 0/9] Add support for memory sealing

[Florian Weimer]

* Jeff Xu:

> Based on the discussion in [1], [2], and [3], it seems that the Nvidia
> drivers issue is related to loading a 32-bit app and has either a
> workaround or a fix. If this is indeed a bug, glibc memory sealing can
> help prevent or detect such a bug earlier.

> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2357062#c11 [1]
> Link: https://bugzilla.rpmfusion.org/show_bug.cgi?id=7180#c25 [2]
> Link: https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/252#note_2918141 [3]

I interpret this comment

| NVIDIA driver releases >= r575 will not do this (broken) patching by default.

<https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/252#note_2918155>

in such a way that the patching code is still there, just disabled by
default.  I don't know what this means from a compatibility perspective.

We have since learned that UCX <https://github.com/openucx/ucx> performs
similar patching.  It commonly shows up on systems as a dependency of
OpenMPI <https://www.open-mpi.org/>, which is one of the more widely
used MPI libraries.

We noticed a while back that the UCX patching does not work on POWER10

  ucx incorrectly patches glibc functions on Power10+ ppc64le systems
  <https://github.com/openucx/ucx/issues/10780>

(it blindly overwrites instructions that it does not recognize).  So I'm
not sure how actively this part of the code is being maintained, and if
there's a chance to move it to a more supportable mechanism.

> There are two solutions for such a case in the future:
> 1. Do not turn on sealing when building the main binary.
> 2. Use the .gnu.mutable solution to mark specific areas/variables to
> be not sealable.

(1) does not work if we are dealing with code that is usually loaded
through dlopen (such as userspace graphics drivers and Python modules).

(2) does not really apply here because this would have to be done during
the glibc build.

Thanks,
Florian