On 9/11/19 2:26 PM, Florian Weimer wrote:
> * Mathieu Desnoyers:
>
>> +#ifdef SHARED
>> + if (rtld_active ())
>> + {
>> + /* Register rseq ABI to the kernel. */
>> + (void) rseq_register_current_thread ();
>> + }
>> +#else
>
> I think this will need *another* check for the inner libc in an audit
> module. See what we do in malloc. __libc_multiple_libcs is supposed to
> cover that, but it's unfortunately not reliable.
>
> I believe without that additional check, the first audit module we load
> will claim rseq, and the main program will not have control over the
> rseq area. Reversed roles would be desirable here.
>
> In October, I hope to fix __libc_multiple_libcs, and then you can use
> just that. (We have a Fedora patch that is supposed to fix it, I need
> to documen the mechanism and upstream it.)
This is a technical issue we can resolve.
>> +/* Advertise Restartable Sequences registration ownership across
>> + application and shared libraries.
>> +
>> + Libraries and applications must check whether this variable is zero or
>> + non-zero if they wish to perform rseq registration on their own. If it
>> + is zero, it means restartable sequence registration is not handled, and
>> + the library or application is free to perform rseq registration. In
>> + that case, the library or application is taking ownership of rseq
>> + registration, and may set __rseq_handled to 1. It may then set it back
>> + to 0 after it completes unregistering rseq.
>> +
>> + If __rseq_handled is found to be non-zero, it means that another
>> + library (or the application) is currently handling rseq registration.
>> +
>> + Typical use of __rseq_handled is within library constructors and
>> + destructors, or at program startup. */
>> +
>> +int __rseq_handled;
>
> Are there any programs that use __rseq_handled *today*?
>
> I'm less convinced that we actually need this. I don't think we have
> ever done anything like that before, and I don't think it's necessary.
> Any secondary rseq library just needs to note if it could perform
> registration, and if it failed to do so, do not perform unregistration
> in a pthread destructor callback.
>
> Sure, there's the matter of pthread destructor ordering, but that
> problem is not different from any other singleton (thread-local or not),
> and the fix for the last time this has come up (TLS destructors vs
> dlclose) was to upgrade glibc.
This is a braoder issue.
Mathieu,
It would be easier to merge the patch set if it were just an unconditional
registration like we do for set_robust_list().
What's your thought there?
--
Cheers,
Carlos.
