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 9:54 AM, Florian Weimer fweimer@redhat.com wrote:
>
>> * Christian Brauner:
>> 
>>>> 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.
>>>
>>> But when you bump ABI in glibc you can switch to a new rseq size, no?
>> 
>> We are expected to support interposers with their own definition
>> __rseq_abi, which could be smaller.
>
> In this scenario, the interposers would have to follow the UAPI rules:
> The size should at least cover the original struct rseq fields,
> up to and including the flags field.

If you use an ELF symbol, you also have to follow rules related to ELF
linking (and C language requirements).

> This just means glibc would internally abide by the same rules as the
> other users if it want to use an extended rseq structure, and not expect
> to be the only possible library defining the __rseq_abi symbol. If glibc
> wants to use the extension feature, it would have to validate that the
> RSEQ_TLS_FLAG_SIZE flag is set in the __rseq_abi.flags, and then validate
> that __rseq_abi.kernel_size covers the feature it needs before accessing
> the feature field.

This still does not give us a way to perform the rseq registration with
the size expected by an interposing definition of __rseq_abi.

I think we are looking at this from the wrong perspective.  It's not
userspace that is setting the size here, it's the kernel based on the
features it supports.  So the kernel should put the size into the
auxiliary vector, and the registration should use that size.  But that
doesn't align well with the use of an ELF TLS symbol.

Thanks,
Florian