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

[Mathieu Desnoyers]

----- On Jul 14, 2020, at 12:01 PM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> The 07/14/2020 11:30, Mathieu Desnoyers via Libc-alpha wrote:
>> > 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.
> 
> this is why it is better to use a function that returns
> a pointer than a tls symbol as public abi.
> 
>> We have a few possible ways to do things here:
>> 
>> 1) Kernel exports supported size, incompatible with ELF TLS symbol,
>> 
>> 2) Userspace dictates supported size, compatible with ELF TLS symbol,
>>    triggers failure if the kernel supports a smaller size,
>> 
>> 3) Userspace lets kernel know how much space is available for struct rseq
>>    (through user_size field), and the kernel lets user-space know how much
>>    of that structure is being filled (through kernel_size field). This
>>    would also be compatible with ELF TLS symbol AFAIU, and would allow
>>    extending struct rseq.
>> 
>> Option (3) would allow us to have the speed gains that come with using a
>> TLS from the fast-path, while allowing extension of struct rseq.
>> 
>> Or is there anything in that scheme that breaks ELF rules or C language
>> requirements ?
> 
> how would users access those extension fields?

if (__rseq_abi.flags & RSEQ_TLS_FLAG_SIZE) {
  /* Allowed to access user_size and kernel_size. */
  if (__rseq_abi.kernel_size >= offsetof(struct rseq, myfield) + sizeof(((struct rseq *)NULL)->myfield)) {
    /* Allowed to access __rseq_abi.myfield. User code should remember this, e.g. in a static variable. */
  }
}

Once the user program/library has confirmed that it can indeed access the field,
it can directly use the field with __rseq_abi.myfield.

> how would the public struct definition change?

Additional fields would be added at the end of struct rseq.
If we use the approach with the end[] flexible array member, then it
would move down to stay at the very end of the structure. If we don't
(because it is not c++ compliant), then we would update an
"rseq_last_field" macro to point to the last field in struct rseq.

Adding additional fields to struct rseq would increase its size due to
added fields, and eventually may change its alignment to a larger value.

Thanks,

Mathieu

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