[PATCH v2] manual: Recommendations for dynamic linker hardening

[Florian Weimer]

* Jonathan Wakely:

>>+@code{STB_GNU_UNIQUE} type do not follow the usual symbol namespace
>>+isolation rules: such symbols bind across @code{RTLD_LOCAL} and
>>+@code{dlmopen} boundaries.  Furthermore, symbol versioning is ignored
>>+for such symbols; they are bound by symbol name only.  All their
>>+definitions and uses must therefore be compatible.  Hidden visibility
>>+still prevents the creation of @code{STB_GNU_UNIQUE} symbols and can
>>+achieve isolation of incompatible definitions.
>
> This still violates the ODR though, right? Would it be worth appending
> to the last sentence something like "at the risk of violating the
> ODR"?
>
> Or does using hidden visibility (which is outside the scope of the
> C++ standard) make them distinct definitions which are then not
> required to be identical?

I think it's the latter, except that you have to hide all the related
compiler-gnerated symbols, and there is no indirect exposure across the
symbol visibility boundary (e.g., pointers to objects on which RTTI is
used).

>>+@code{RTLD_LOCAL} or @code{dlmopen}.
>>+
>>+This can cause issues in applications that contain multiple incompatible
>>+definitions of the same type.
>
> Which is why the ODR disallows it.

Yes, but RTLD_LOCAL and dlmopen are supposed to deal with such issues.

>
>>+@item
>>+C++ exception handling across multiple @code{dlmopen} namespaces may
>>+not work, particular with the unwinder in GCC versions before 12.
>>+Current toolchain versions are able to process unwinding tables across
>>+@code{dlmopen} boundaries.  However, note that type comparison is
>>+name-based, not address-based (see the previous item), so exception
>>+types may still be matched in unexpected ways.  An important special
>>+case of exception handling, invoking destructors for variables of block
>>+scope, is not impacted by this RTTI type-sharing.  Likewise, regular
>>+virtual member function dispatch for objects is unaffected (but still
>>+requires that the type definitions match in all directly involved
>>+translation units).
>>+
>>+@item
>>+The Itanium C++ ABI requires that in some cases, C++ destructors for
>>+global objects that are constructed on demand are not destructed in the
>
> s/destructed/destroyed/
>
> Also, this sentence says "destructors [...] are not destructed" but it
> means that the global objects are not destroyed, rather than the
> destructors for the global objects.

I used your suggestion below instea.

>>+opposite order of their construction.  (The C++ standard requires
>>+opposite constructor order.)  As a result, do not depend on the precise
>
> I had to read this a couple of times to decide if "opposite
> constructor order" means something different from "opposite order of
> their construction". I think the parenthesis could be made clearer, so
> it's more obviously saying that the previous sentence describes a
> deviation from the C++ standard. Maybe:
>
> "Although the C++ standard requires that destructors for global
> objects run in the opposite order of their constructors, the Itanium
> C++ ABI requires a different destruction order in some cases. As a
> result, do not rely ..."

Makes sense.

>>+@item
>>+Do not use a binutils release that is older than the one used to build
>>+@theglibc{} itself.
>
> Is the binutils version used to compile glibc readily available to
> users who install glibc from their distro?

It's the job of the distribution to ensure consistency. 8-)

>>+@option{-Wl,-soname,lib@dots{}} to set a soname that matches the final
>>+installed name of the file.
>>+
>>+@item
>>+Do not use the @option{-rpath} linker option.
>
> It's not clear from the preceding text why this option is a problem.

I added “Changing the default linker search path is not recommended.”
The intent here is to install the shared objects into the default
location, so that it becomes more obvious to the integrator if
there is a filen ame/soname collision.

Thanks,
Florian