Re: Proposal for simpler libc rseq registration ABI across libraries

[Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>]

----- On Mar 22, 2019, at 4:51 PM, Carlos O'Donell codonell@redhat.com wrote:

> On 3/22/19 4:27 PM, Mathieu Desnoyers wrote:
>> Hi,
>> 
>> Here is a email thread dedicated to discuss a simpler ABI proposal for
>> interaction between libc and early adopter libraries/applications with
>> respect to registration of restartable sequences (rseq).
>> 
>> This is based on my current proposal
>> "glibc: Perform rseq(2) registration at C startup and thread creation (v7)"
>> https://lore.kernel.org/patchwork/patch/1041324/
>> 
>> We can move the __rseq_lib_abi TLS refcount and register_state to an external
>> library (librseq).
>> 
>> glibc would expose a new global "int" variable symbol __rseq_handled acting as
>> a boolean. It would be initially 0. glibc would set it to 1 in its C startup
>> code when it effectively handles rseq registration. That symbol would _not_ be
>> a TLS (it's global).
>> 
>> librseq would be a new library used by rseq early adopters. It would expose a
>> rseq register/unregister API, which internally would:
>> 
>> - Check whether __rseq_handled is true. If so, it would do nothing, leaving
>>    rseq registration to the libc.
>> - If __rseq_handled is false, deal with many early adopters with TLS refcount
>>    and register_state variables internal to librseq.so.
>> 
>> That should take care of minimizing those metrics:
>> - libc ABI complexity and maintenance burden in the long term,
>> - pain for rseq early adopters when upgrading to newer libc which supports rseq
>>    registration,
>> 
>> Does that make sense ?
> 
> Yes. Is the presence of __rseq_handled enough (depends on how you handle
> linkage)?

I would define a "int __rseq_handled" within both librseq and glibc.

Only glibc would set it to 1 in the C startup code.

librseq would only read its value to figure out if glibc handles registration.

It would require that the __rseq_handled symbol is not hidden, and that both
glibc and librseq populate their symbols into the global symbol table.

If glibc *and* librseq are linked into a process, then the dynamic linker
will end up choosing one instance of __rseq_handled and put it in the global
symbol table.

If either glibc or librseq are loaded, then we end up having a single
instance of the __rseq_handled symbol to place in the table, which is also
fine.

> 
> I think it's a reasonable design to use a symbol as feature detection for a
> feature that exposes no API.
> 
> The alternative would be to implement an rseq wrapper and use the presence of
> that wrapper to determine if libc was doing registration. So we use a known and
> possibly required wrapper to implement the feature without needing another symbol.

I fear I'm not fully getting this last idea.

That wrapper would be a function with a public symbol, right ? Where would it be
implemented ? glibc or librseq ?

Assuming it sits in glibc, how would librseq be able to link against an older
glibc which does not contain this symbol, and eventually upgrade to a newer glibc
which contains this symbol (and handles rseq registration) ?

I'm clearly missing something here.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com