Need a mechanism to disable glibc rseq for binaries with capabilities

[Florian Weimer]

* Ashok Dwarakinath:

> We have a binary with CAP_SYS_ADMIN capability that is started by a
> non-root user. This binary is linked to Google tcmalloc. The service
> has a lot of threads, so it benefits from tcmalloc per-CPU caches. We
> are migrating to glibc 2.34 (RHEL 9) which enables glibc rseq by
> default. This results in google tcmalloc disabling per-CPU cache
> support (https://github.com/google/tcmalloc/issues/144).  We found
> that disabling rseq using GLIBC_TUNABLES doesn't work for binaries
> with capabilities set. So, we need a different mechanism to make this
> work. Thoughts?

Thanks for raising this.  My idea for tackling this would be by giving
binaries a way to embed tunable strings, and those tunable strings would
not be ignored for AT_SECURE binaries because they are trusted due to
their source.  At this point, I think we shouldn't add something that
explicitly disables RSEQ.  Binaries that disable RSEQ this way would
still have to be compatible with RSEQ usage in glibc (possibly with
reduced performance, similar to running in containers/on kernels which
do not support RSEQ).

Regarding mechanism, we could define a new note type

#define NT_GNU_LIBC_TUNABLE 6

and specify that it's a single tunable value: tunable name, followed by
'=', followed by the tunable value, followed by null terminator.
Multiple tunables would have to use separate notes.

The tricky part is that we probably want to retain the capability for
GLIBC_TUNABLES to override the settings in binaries (if AT_SECURE is not
active).  This means that we'd have to move the __tunables_init call
much later.  I don't think that's an insurmountable problem, but it
makes the change not quite straightforward.

Does this sound like a plan?

Thanks,
Florian