GNU libc support for extensible rseq ABI

GNU libc support for extensible rseq ABI

[Mathieu Desnoyers]

Hi Carlos, Florian,

Now that the 6.3 Linux kernel is out, the ABI for extensible rseq is 
frozen, and we could add support for it in glibc. It would be good to 
upstream this support before we run out of room in the padding space we 
currently re-use.

What glibc release should we target for this ?

You can find the librseq code supporting the extensible rseq ABI here:

https://git.kernel.org/pub/scm/libs/librseq/librseq.git/

specifically under src/rseq.c.

Thanks!

Mathieu

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

Re: GNU libc support for extensible rseq ABI

[Florian Weimer]

* Mathieu Desnoyers:

> Hi Carlos, Florian,
>
> Now that the 6.3 Linux kernel is out, the ABI for extensible rseq is 
> frozen, and we could add support for it in glibc. It would be good to 
> upstream this support before we run out of room in the padding space we 
> currently re-use.
>
> What glibc release should we target for this ?

It may be possible to hack this into the existing TLS allocator.  See
the loop in _dl_determine_tlsoffset.  It should be possible to add the
rseq area as another static TLS block (perhaps as the first one before
the loop), with the size and alignment requested by the kernel.  If we
can make that work, it's going to be a fairly small patch that should
be backportable as well.  That could go into 2.38 or 2.39.

If we need a new TLS allocator, it's definitely 2.39 material at this
point, potentially later.

Re: GNU libc support for extensible rseq ABI

[Mathieu Desnoyers]

On 2023-05-18 14:06, Florian Weimer wrote:
> * Mathieu Desnoyers:
> 
>> Hi Carlos, Florian,
>>
>> Now that the 6.3 Linux kernel is out, the ABI for extensible rseq is
>> frozen, and we could add support for it in glibc. It would be good to
>> upstream this support before we run out of room in the padding space we
>> currently re-use.
>>
>> What glibc release should we target for this ?
> 
> It may be possible to hack this into the existing TLS allocator.  See
> the loop in _dl_determine_tlsoffset.  It should be possible to add the
> rseq area as another static TLS block (perhaps as the first one before
> the loop), with the size and alignment requested by the kernel.  If we
> can make that work, it's going to be a fairly small patch that should
> be backportable as well.  That could go into 2.38 or 2.39.
> 
> If we need a new TLS allocator, it's definitely 2.39 material at this
> point, potentially later.

Michael (in CC) showed interest in working on this. I'm adding him to 
this e-mail thread so you are both aware of each other's ongoing progress.

Thanks,

Mathieu

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