[RFC 3/5] elf: Add support to memory sealing

[Mike Hommey]

On Tue, Jun 11, 2024 at 12:27:06PM -0300, Adhemerval Zanella wrote:
> The new Linux mseal syscall allows seal memory mappings to avoid
> further changes such as memory protection or remap.  The sealing
> is done in multiple places where the memory is supposed to
> be immutable over program execution:
> 
>   * All shared library dependencies from the binary, including the
>     read-only segments after PT_GNU_RELRO setup.

For what it's worth, this will break current Firefox binaries from
mozilla.org.

Why? Long story short, they are linked with both -Wl,-z,pack-relative-relocs
and -Wl,-z,relro, but because they need to run on old and new systems,
and because the first glibc insists that a binary using RELR relocations
_has_ to have a dependency on the GLIBC_ABI_DT_RELR symbol version,
which is not backwards compatible with older glibcs, the Firefox
binaries are edited to change the DT_RELR tags to something else,
and they contain an init function that applies the relocations instead
of ld.so. That code also temporarily undoes the RELRO madvise to be
able to apply those relocations, and redoes it afterwards.

mseal would prevent that temporary undoing from working and make Firefox
crash on startup.

Had the GLIBC_ABI_DT_RELR symbol version not been a hard requirement, we
wouldn't have ended up in this situation, but here we are.

I'm not sure what the best way to handle the situation would be.
Obviously, there are hackish ways to handle the situation, like removing
the PT_GNU_RELRO and applying it and the mseal manually.

One question is, should a binary be able to opt out of the seal for
whatever reason, individually? (rather than the global tunable, which a
binary can't opt-into on its own, too, although in Firefox's case,
there's a wrapper binary that could set GLIBC_TUNABLES...).

Sorry for the rambling. All the gory details on https://glandium.org/blog/?p=4297.

Mike