Bringing rseq back into glibc

Florian Weimer fweimer@redhat.com
Thu Nov 18 19:43:53 GMT 2021


* Mathieu Desnoyers:

> ----- On Nov 18, 2021, at 1:48 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
>
>> On Thu, Nov 18, 2021 at 7:17 AM Florian Weimer via Libc-alpha
>> <libc-alpha@sourceware.org> wrote:
>> 
>>> 4. Add public symbols __rseq_abi_offset, __rseq_abi_size (currently 32
>>>    or 0), __rseq_abi_flags (currently 0).  __rseq_abi_offset is the
>>>    offset to add to the thread pointer (see __builtin_thread_pointer) to
>>>    get to the rseq area.  They will be public ABI symbols.  These
>>>    variables are initialized before user code runs, and changing the
>>>    results in undefined behavior.
>> 
>> Why not then __get_rseq_whatwever functions and not variables ? or
>> maybe writing to these variables results in a compiler or linker error
>> instead of UB ?
>
> rseq critical sections cannot issue function calls, and also function calls
> are noticeably expensive compared to an rseq critical section. So all users
> would end up needing to make a local copy of the information fetched by those
> getters.
>
> So rather than require all those extra per-user copies, I suspect exposing
> a single copy through public glibc symbols is more efficient.

Right, and users that want the last bit of performance can still create
local copies.

> The downside is indeed that writing to those variables is UB.

So is writing garbage to the rseq area. 8-) I will see if we can declare
this variables as extern const, and make writes to them terminate the
process.

Thanks,
Florian



More information about the Libc-alpha mailing list