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

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Jul 14, 2020, at 1:03 PM, Florian Weimer fweimer@redhat.com wrote:

> * 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. */
>>   }
>> }
> 
> Technically, this needs a compiler extension, so that the allowed
> accesses to the __rseq_abi.myfield field are not moved before the flags
> and size checks.

If those accesses are performed as volatile loads, or with atomic relaxed
semantic, the compiler should not be allowed to change the order. Likewise
if we use asm volatile (::: "memory") clobber between the loads.

Thanks,

Mathieu

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