Need a mechanism to disable glibc rseq for binaries with capabilities

[Adhemerval Zanella Netto]

On 27/01/26 13:24, Florian Weimer wrote:
> * 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).

Doing this would make the tunable a de-facto ABI, which would require to
always support the current set of tunables and options.  We currently
specify that:

 22 Tunables are not part of the @glibcadj{} stable ABI, and they are
 23 subject to change or removal across releases.

And this gives some freedom to avoid adding *another* future-proof
ABI semantic we will need to take care and keep compatibility.  

For instance, with b9579342c68baf0beacfb4e93b9a6a325d3f9527 we remove
the lock-elision support and all the related tunables.  Which is the
expectation of binaries with an embedded tunable on a future glibc
that either change the semantic or just remove the tunable altogether?

And it should be valid even for security hardening tunables, like
aarch64 BTI or GCS (where eventually we might just make the switch
to always enable it, or just move the support some other binary
marking).

What I think it would be better is to add a GNU attribute, similar to
what I tried to do with memory sealing, to disable RSEQ setup.  This
would be need to be proper described and defined in gABI, along with
a linker patch.

It is more work, but by defining the proper semantic without resorting
the glibc implementation detail (tunable) would a more robust way
forward.

> 
> 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
>