Comment # 5 on bug 1200030 from Egbert Eich

There has been an email by Marcus Meissner shedding some more light on the
changes made in TW:
=======================================
Betreff: Default enabling -z now aka "Full RelRO" in Factory
Datum: Tue, 5 Apr 2022 11:24:47 +0200
Von: Marcus Meissner
Organisation: SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 
Nuernberg, Germany, GF: Ivo Totev, HRB 36809, AG N���rnberg
An: factory@lists.opensuse.org

Hi folks,

Security hardening of Linux systems suggests marking ELF binary sections
as much read-only as it gets.

A part of this binary hardening is making the ELF relocations in 
binaries and
libraries read-only to avoid them being overwritten and used for attacks.

SUSE has built everything with "Partial RELRO" for a long time (via
a default in binutils). (-z relro)

We did not yet do "Full RELRO" (-z now) as we feared the amount of 
integration
work.

However as this is industry standard now, we have started the
integration and will push it to main Factory / Tumbleweed soon.

It is being implemented by:

- The SUSE binutils "ld" queries the "SUSE_ZNOW"  environment variable.
   If it is present and not "0", it will enable "-z now".

- The post-build-checks injects via /etc/profile.d/build-system.sh the
   environment variable SUSE_ZNOW=1 into all RPM build chroots (that use
   post-build-checks, which should be all of them).

- Packages can still deselect it.

   Either:
   - use linker option "-z lazy".
   - or export SUSE_ZNOW=0 in the %build section.

Currently only "xorg-x11-server" and "python-atspi:tests" needed to do this
in our staging.

After this is integrated in on the next snapshots, if you see weird
symbol lookup errors, as usual report them via bugzilla.

Ciao, Marcus
===========================================

With this in mind, we need to look at ways to address this.
It is quite conceivable that a plugin uses code provided by the application
that dlopen()s the plugin: after all the plugin is used to extend the
functionality of the main program with parts that are deemed optional or mutual
exclusive. It is also not unheard of that plugins which are used in multiple
contexts carry functionality that is only used in a subset of cases.
To address this, we need to:
a. understand better what the 'industry standard' that Marcus refers to means 
   exactly - ie. who else has adopted this change in what time frame (ie which 
   product) as this is important data when raising the issue with upstream.
b. find a viable way to address the problem - ie by using weak symbols. Now, 
   plugins already use 'weak_import' for some data in plugins on Apple systems 
   already  - while defining the same data locally on all other systems.
   Thus, we need to determine what will work for function calls and get an 
   estimate how many such calls will be affected as it expected that the
problem 
   at hand is only the tip of the iceberg.

@Marcus, would you be able to provide further information on what you refer to
as 'industry standard' in your email above?