Re: [RFC PATCH glibc] Linux: Use fixed rseq_len value for rseq registration

[Florian Weimer <fweimer@redhat.com>]

* Mathieu Desnoyers:

> ----- On Jul 14, 2020, at 4:51 AM, Florian Weimer fweimer@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>> 
>>> +  /* The rseq_len parameter does not allow extending struct rseq.  Fix its
>>> +     value to 32 as expected by the Linux kernel.  */
>>> +  ret = INTERNAL_SYSCALL_CALL (rseq, &__rseq_abi, 32, 0, RSEQ_SIG);
>> 
>> If the layout of struct rseq can change in the kernel headers, than far
>> more significant changes are needed.  glibc cannot change its ABI
>> depending on the version of the kernel headers it is compiled against.
>
> What I have in mind for struct rseq is that the current structure layout
> is guaranteed as a "minimum" requirement. It can then be extended by the
> kernel UAPI in a backward compatible way: if user-space provides enough
> room for extension, and the kernel supports the additional features, then
> user-space can use those additional features.
>
> Adding extra room in the __rseq_abi can be done though:
>
> - Upgrading glibc with knowledge of the extra layout,
> - Preloading an interposition library which defines __rseq_abi with the
>   extended layout,
> - Defining __rseq_abi with extended layout in the application binary.
>
> What I suspect is your concern here is that two glibc-2.32 builds against
> different versions of kernel headers could lead to different __rseq_abi
> size, which is unexpected.

Indeed.

> Would using the internal struct rseq all the time in glibc (rather than
> uapi linux/rseq.h) resolve your concern ? This way, glibc could integrate
> extended layouts on version bump (e.g. 2.33).

It works reliably as long as glibc only ever uses the minimum rseq size.
And since glibc monopolizes the rseq registration, applications cannot
register a larger area.  So there is no way to make use of any future
kernel extensions.

Thanks,
Florian